-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mount_NETFS_path issue #991
Comments
@gigawatts try running with the debug option turned on to see where it goes wrong. To be honest I never used this option myself (I believe @schlomo wrote this piece) |
I debug this issue further and below are my observations. // From backup/NETFS/default/10_mount_NETFS_path.sh AddExitTask "rmdir $v $BUILD_DIR/outputfs >&2" if [[ "$BACKUP_MOUNTCMD" ]] ; then mount_url $BACKUP_URL $BUILD_DIR/outputfs $BACKUP_OPTIONS <<<<<< this is where actual failure is triggered So it means $BACKUP_URL is not correct. I added debug statement here and got below : 2016-09-14 04:37:53 amote var://BACKUP_UMOUNTCMD.. /tmp/rear.iAtsBx6RCk9ODs2/outputfs.. rw,noatime ...... It means $BACKUP_URL is set to var://BACKUP_UMOUNTCMD which is causing this issue. Checking further, I see that BACKUP_URL is set in below two places which is relevant to our analysis : I ran "rear -v mkbackup" command and observed logs from /var/log/rear/rear-rhel7.log file. Along with this, I added debug statement in other places as well. When mkbackup command is run, it go through all below stages :
During 'prep' stage, I see that 98_umount_NETFS_dir.sh is sourced and that's where BACKUP_URL gets set. // from 98_umount_NETFS_dir.sh , as we have set BACKUP_UMOUNTCMD in site.conf file, if is true and then set BACKUP_URL
2016-09-14 05:16:31 Running 'prep' stage 2016-09-14 05:16:31 amoteSource.../usr/share/rear/prep/NETFS/default/98_umount_NETFS_dir.sh... <<<<<<<< 2016-09-14 05:16:31 Finished running 'prep' stage in 0 seconds 2016-09-14 05:16:31 Running 'layout/save' stage Now during last 'backup' stage, 10_mount_NETFS_path.sh script access BACKUP_URL variable which is already set in 'prep' stage to "var://BACKUP_UMOUNTCMD". Because of this, its getting failed here. To workaround this issue, I defined NETFS_MOUNTCMD in site.conf file and "rear -v mkbackup" is properly executed without any failure. |
@gigawatts @ajitmote In the latest development release of ReaR we have modified the exit messages so that the |
The initial comment We define a custom NETFS_UMOUNTCMD variable in our site.conf, with a function that basically spits out a backup complete message, along with a timestamp and where the backup was stored ... A better option (for us) would be a variable we could set that would run at the very end ... to avoid having to hijack the umount command in the way that we do. Does something like that already exist? I think one cannot expect that misuse of NETFS_UMOUNTCMD NETFS_UMOUNTCMD is deprectated. BACKUP_UMOUNTCMD is meant to be used together To run arbitrary commands at the very end use To spit out a backup complete message see I think this issue is sufficiently answered via |
NETFS_UMOUNTCMD
variable in our site.conf, with a function that basically spits out a backup complete message, along with a timestamp and where the backup was stored so that we can insert that result into a database. The problem is that it seems during thebackup/NETFS/default/10_mount_NETFS_path.sh
script step, it is trying to run this above custom defined UMOUNT command instead of a stock MOUNT command, even though theNETFS_MOUNTCMD
variable is not defined. See the Mounting with line below from my log. Besides failing to mount, since it is running the wrong command, it does not error out, and continues writing the tar.gz file to the /tmp/rear.xxxx directory, filling up the /tmp filesystem.I even modified the
backup/NETFS/default/10_mount_NETFS_path.sh
script, for debug purposes, to spit out the contents of all the MOUNTCMD and UMOUNTCMD variables, and none of the UMOUNT variables contain anything, so I don't know where its picking this botched mount command up from.It doesn't seem to matter if I set BACKUP_UMOUNTCMD or NETFS_UMOUNTCMD to my custom umount function, same result either way.
One other thought, we store both the ISO and BACKUP in the same spot on our NFS server, but during the course of the rear mkbackup, the NFS share is mounted and un-mounted 3 times, I believe. Is there any way to let it stay mounted the whole time so only 1 mount and 1 un-mount is required? The first 2 mounts and un-mounts work just fine, its only that 3rd / last mount, during the backup phase, that fails.
A better option (for us) would be a variable we could set that would run at the very end, perhaps during
backup/NETFS/default/98_umount_NETFS_dir.sh
script, to avoid having to hijack the umount command in the way that we do. Does something like that already exist? I didn't turn up anything obvious in my search.Thank you in advance for any help you can provide.
The text was updated successfully, but these errors were encountered: