borgbackup
`borg mount` does not show return code
Is this a BUG / ISSUE report or a QUESTION?
BUG
System information. For client/server mode post info for both machines.
Your borg version (borg -V).
borg 1.2.0
Full borg commandline that lead to the problem (leave away excludes and passwords)
BORG_PASSPHRASE=XXX borg mount --show-rc
Describe the problem you're observing.
borg mount does not show the return code if asked to.
$ BORG_PASSPHRASE=XXX borg mount --show-rc <repo>::2024-07-28T03-00-01 /mnt/backup_restore
# no return code, just empty output
$
There seems to be something wrong with the printing. Normally there should be an empty line before the new command prompt. Should look like this:
$ BORG_PASSPHRASE=XXX borg mount --show-rc <repo>::2024-07-28T03-00-01 /mnt/backup_restore
# no return code, just empty output, should print rc
$
Running any other commands shows the rc
$ borg list --show-rc --last 1
2024-07-28T03-00-01 Sun, 2024-07-28 03:01:51 [39a743e40e24c419462e587451ce55bd3934d096d0af0a7338f2b3f295c196f1]
terminating with success status, rc 0
$
or
$ borg umount --show-rc /mnt/backup_restore
terminating with success status, rc 0
$
or
$ borg info --show-rc
Repository ID: ...
Location: ...
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/....
Security dir: /root/.config/borg/security/...
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
All archives: 1.43 TB 1.43 TB 131.58 GB
Unique chunks Total chunks
Chunk index: 107845 1214072
terminating with success status, rc 0
$
$ BORG_PASSPHRASE=XXX borg mount --show-rc <repo>::2024-07-28T03-00-01 /mnt/backup_restore
# no return code, just empty output
$
If you don't use the --foreground option, borg forks a background process that keeps running until you umount. The foreground process terminates, but there isn't much useful to report via rc or via --show-rc output.
Guess we could implement supporting this (for consistency), but it wouldn't be very useful. Not sure what happens if the foreground process runs into an issue before or after forking.
If you use --foreground, borg does not fork, try if --show-rc works with that. Would also make more sense at the end because then the rc could really report some sort of "outcome".
BTW, 1.2.0 is relatively old. If you run debian or ubuntu, try backports or the ppa.
BTW, 1.2.0 is relatively old. If you run debian or ubuntu, try backports or the ppa.
I upgraded to borg 1.4.0 from the ppa now. The following output is all from borg 1.4.0
Guess we could implement supporting this (for consistency), but it wouldn't be very useful.
I don't see why it should not be useful. I run borg in a script and would like to see all the returncodes in text to see whether everything worked as expected. And at least for consitency it should be implemented (in my opinion).
If you use --foreground, borg does not fork, try if --show-rc works with that.
I tried that. However the command seems to hang somewhere. It does mount the repo but the command does not finish.
$ borg mount :: backup_restore/ --show-rc --foreground
^C^C/usr/lib/python3/dist-packages/trio/_core/_run.py:2235: RuntimeWarning: Trio guest run got abandoned without properly finishing... weird stuff might happen
terminating with success status, rc 0
See the CTRL + C I had to do. When I don't use --foreground the command finishes as expected (but does not print the rc).
Here the output with a --debug:
$ borg mount :: backup_restore/ --show-rc --foreground --debug
using builtin fallback logging configuration
33 self tests completed in 0.20 seconds
SSH command line: ['ssh', 'xxx@yyy', 'borg', 'serve', '--debug']
Remote: using builtin fallback logging configuration
Remote: 33 self tests completed in 0.16 seconds
Remote: using builtin fallback logging configuration
Remote: Initialized logging system for JSON-based protocol
Remote: Resolving repository path b'xxx'
Remote: Resolved repository path to 'xxx'
Remote: Verified integrity of xxx/index.940
TAM-verified manifest
security: read previous location 'xxx'
security: read manifest timestamp '2024-07-28T01:09:39.019014'
security: determined newest manifest timestamp as 2024-07-28T01:09:39.019014
security: repository checks ok, allowing access
mount data cache capacity: 4 chunks
Mounting filesystem
Initializing pyfuse3
Calling fuse_session_new
Calling fuse_session_mount
pyfuse-02: No tasks waiting, starting another worker (now 2 total).
^C^C/usr/lib/python3/dist-packages/trio/_core/_run.py:2235: RuntimeWarning: Trio guest run got abandoned without properly finishing... weird stuff might happen
Calling fuse_session_destroy
RepositoryCache: current items 0, size 0 B / 2.15 GB, 0 hits, 0 misses, 0 slow misses (+0.0s), 0 evictions, 0 ENOSPC hit
RemoteRepository: 236 B bytes sent, 3.27 kB bytes received, 5 messages sent
terminating with success status, rc 0
It says tarting another worker (now 2 total) which is the amount of CTRL + C (2) I need to stop the process.
It doesn't "hang", it is just quite silent if you don't use --debug. It needs to keep running to serve the FUSE requests, so that you can work with the files in the mounted borgfs filesystem.
The process ends if you:
- umount
- kill it somehow (e.g. Ctrl-C) - after that, the mount is dysfunctional
What I meant by "not that interesting" without --foreground: there are 2 borg processes which result in a return code when they terminate:
- the foreground borg process: it does argument parsing, forks the background process and then terminates. that's not much what it does and it terminates before the background process.
- the background borg process: runs in background and terminates usually long after the command you have invoked (== the foreground process), so its RC is not available to the caller.
BTW, read and follow the upgrade notes when upgrading from 1.2.0 to 1.4.0, esp. the CVE related upgrade instructions at the top of the changelog.
It doesn't "hang", it is just quite silent if you don't use --debug. It needs to keep running to serve the FUSE requests, so that you can work with the files in the mounted borgfs filesystem.
That makes sense^^. So back to the original issue: I'd find a --show-rc option nice. However, if you don't agree feel free to close this issue.
BTW, read and follow the upgrade notes when upgrading from 1.2.0 to 1.4.0, esp. the CVE related upgrade instructions at the top of the changelog.
Thank you. Done!