Bug 2188385

Created attachment 1958590 [details]
File: open_fds

Created attachment 1958591 [details]
File: environ

Created attachment 1958592 [details]
File: cpuinfo

Created attachment 1958593 [details]
File: namespaces

Created attachment 1958594 [details]
File: os_info

Created attachment 1958595 [details]
File: backtrace

Created attachment 1958596 [details]
File: mountinfo

@pizza Do you have any additional information on this failure?

Firstly, has this been working before, and is now failing?
Was it working under a previous version of rdiff-backup or Fedora?
Can you connect to the remote host with the user listed?
Is rdiff-backup installed on the remote machine?
Does the directory you are backing up to exist, and is it writeable?
Is there any other information you can supply?

Finally are you able to run the backup with a higher level of verbosity, e.g. -v5 or even -v9?

I recently upgraded the system from up-to-date F37 to F38 beta (now final).  It was working fine prior to the upgrade, and seems to work if I kick off the backup run manually (normally it's executed by cron)

...I saw this error pop up in abrt, presumably due to it failing in a cron-invoked run, so I reported it thinking it had to do with the F38 upgrade.

The server is running up-to-date F37.

Unless a transient network connectivity failure can result in the error that was reported, I'm at a loss as to its cause.

Thanks for the additional information.

Does it seem to be running fine from cron since then, or does it still come up with failures?

My test setup which has f37 for the server and has an f38 client is working fine, so it is not a generic issue, but obviously something did upset it there, and we want to get to the bottom of it.

If you don't have any more info, I'll take it up stream and see if they can suggest what may have caused it.  Normally they respond pretty quickly.

If it does become more of a problem for you, I'll dig into it a bit more myself.

Submitted upstream issue #868 (https://github.com/rdiff-backup/rdiff-backup/issues/868)

At this point it seems to be running okay, manually and via cron alike.

I don't know if there is anything for upstream can do, short of perhaps trapping these exceptions and reporting a more user-friendly error message.

Solomon,

An interesting response from upstream, and primarily they agree that trapping it and generating a better message will be looked at.

The actual response from Eric L:

> Actually, it might very much have been a network issue, I did a very simple test and get the following error:
> 
> $ rdiff-backup backup . doesnotexist::/tmp/bak
> ssh: Could not resolve hostname doesnotexist: Name or service not known
> ERROR: Couldn't start up the remote connection by executing 'ssh -C doesnotexist rdiff-backup --terminal-verbosity 3 --server'
> due to exception 'Truncated header <b''> (problem probably originated remotely)'.
> 
> Remember that, under the default settings, rdiff-backup must be
> installed in the PATH on the remote system.  See the man page for more
> information on this.  This message may also be displayed if the remote
> version of rdiff-backup is quite different from the local version (2.2.4)
> 
> Traceback (most recent call last):
>   File "/usr/bin/rdiff-backup", line 33, in <module>
>     sys.exit(load_entry_point('rdiff-backup==2.2.4', 'console_scripts', 'rdiff-backup')())
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/lib64/python3.11/site-packages/rdiffbackup/run.py", line 37, in main
>     sys.exit(main_run(sys.argv[1:]))
>              ^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/lib64/python3.11/site-packages/rdiffbackup/run.py", line 85, in main_run
>     with action.connect() as conn_act:
>          ^^^^^^^^^^^^^^^^
>   File "/usr/lib64/python3.11/site-packages/rdiffbackup/actions/backup.py", line 63, in connect
>     self.repo = repository.Repo(
>                 ^^^^^^^^^^^^^^^^
>   File "/usr/lib64/python3.11/site-packages/rdiffbackup/locations/repository.py", line 70, in __init__
>     self.data_dir = self.base_dir.append_path(b"rdiff-backup-data")
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^
> AttributeError: 'NoneType' object has no attribute 'append_path'
> Still, I don't quite understand the final traceback and we should get rid of it to fail more gracefully, but that should be simple enough.

Is there anything else we can do here, or should I just close this request?

Upstream has improved the test and messaging and it will be available in the next release of rdiff-backup.