Opened 8 years ago

Closed 8 years ago

#496 closed defect (fixed)

Mondoarchive doesn't seem to recognize the fact that the sshfs file system is already mounted.

Reported by: aepittman Owned by: bruno
Priority: normal Milestone: 3.0.0
Component: mondo Version: 2.2.9.7
Severity: normal Keywords: sshfs
Cc:

Description (last modified by bruno)

Mondoarchive doesn't seem to recognize the fact that the sshfs file system is already mounted.

As you can see from the output below, the sshfs file system is mounted, with a mountpoint of /mnt.

The second "df -kv" listed below is after mondoarchive finishes and the fusermount -u command is executed to un-mount /mnt

[root@taeps002 ~]# ./mondo_backup.sh
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p1    134414668   3881292 123595308   4% /
/dev/cciss/c0d1p1    137789964    192132 130485460   1% /data1
tmpfs                  1029292         0   1029292   0% /dev/shm
sshfs#taep@taeps001.publix.com:/clonefs
                     346729196 179680420 149435916  55% /mnt

Initializing...
See /var/log/mondoarchive.log for details of backup run.
Checking sanity of your Linux distribution
Done.
Network share is not mounted. Trying to mount it for you.
fuse: missing mountpoint
Unable to mount Network share taeps001.publix.com:/clonefs. Please mount manuall
sh: /taeps002.publix.com/.dummy.txt: No such file or directory
Are you sure directory 'taeps002.publix.com' exists in remote dir 'taeps001.publ
Errors were detected in the command line you supplied.
Please review the log file - /var/log/mondoarchive.log
Execution run ended; result=1
Type 'less /var/log/mondoarchive.log' to see the output log
./mondo_backup.sh: line 25:  4607 Segmentation fault      /usr/sbin/mondoarchive -OVn sshfs://taep@$BACKUP_SERVER:/clonefs -d $HOST -p $HOST -E $LOCAL_MOUNTP -s 4G -z -K 99

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p1    134414668   3881320 123595280   4% /
/dev/cciss/c0d1p1    137789964    192136 130485456   1% /data1
tmpfs                  1029292         0   1029292   0% /dev/shm

Attachments (2)

taeps002-20110729-mondoarchive.log (8.1 KB) - added by aepittman 8 years ago.
taeps002-20110729-mindi.log (9.3 KB) - added by aepittman 8 years ago.

Download all attachments as: .zip

Change History (10)

Changed 8 years ago by aepittman

Changed 8 years ago by aepittman

comment:1 Changed 8 years ago by aepittman

Although I don't have any log files for this, the same problem occurs with Mondorescue on a SLES11 server.

comment:2 Changed 8 years ago by bruno

  • Description modified (diff)
  • Status changed from new to assigned

comment:3 follow-up: Changed 8 years ago by bruno

In order for me to diagnose correcty, could you also attacht eh result of the mount command when your sshfs FS is mounted please ? (analyze done at libmondo-cli.c line 526)

comment:4 in reply to: ↑ 3 Changed 8 years ago by aepittman

Replying to bruno:

In order for me to diagnose correcty, could you also attacht eh result of the mount command when your sshfs FS is mounted please ? (analyze done at libmondo-cli.c line 526)

Bruno,

Before I post an update in trac, I wanted to know if this information is enough. Personally, I think it's worthless.

I added the debug option to the sshfs mount command:

/usr/bin/sshfs -o sshfs_debug taep@$BACKUP_SERVER:/clonefs $LOCAL_MOUNTP

But the only output I got was this:

SSHFS version 2.2 Server version: 3 Extension: posix-rename@… <1> Extension: statvfs@… <2> Extension: fstatvfs@… <2>

I'm sure you are looking for something with some detailed, but I'm not sure what options to use to give you the information you need. Can you give me a suggestion or two?

Alan

comment:5 Changed 8 years ago by bruno

What I really would like to get is twhat gives your system when you type mount. Mondorescue analysis the result of this to detect whether the FS is mounted or not, and I guess that with your version, that detection is incorrect.

I also published a new beta (under ftp://ftp.mondorescue.org/test) that is fixing some issues at restore time around mount, and some other at backup time with sshfs you mentioned earlier, but probably not that specific one.

comment:6 Changed 8 years ago by bruno

In another case I found the following:

mount result:


/dev/cciss/c0d0p1 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/cciss/c0d1p1 on /data1 type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
sshfs#taep@taeps001.publix.com:/clonefs on /mnt type fuse (rw,nosuid,nodev,max_read=65536)

So it seems that some mount commands give in addition the protocol before the mount point. I have add support for that syntax with rev [2877]. I'm regenerating rhel5 packages (available at ftp://ftp.mondorescue.org/test/rhel/5) for you to test nd report back again.

Thanks for your patience on this.

comment:7 Changed 8 years ago by aepittman

I have downloaded and applied the following RPMs for RHEL5:

[root@taeps002 tmp]# ll *el5.x86_64* -rwxr--r-- 1 root root 76844 Oct 5 15:21 afio-2.5-1.rhel5.x86_64.rpm -rwxr--r-- 1 root root 22145 Oct 5 15:21 buffer-1.19-4.rhel5.x86_64.rpm -rwxr--r-- 1 root root 53026 Oct 5 15:21 fuse-sshfs-2.2-5.el5.x86_64.rpm -rwxr--r-- 1 root root 252156 Oct 5 15:21 mindi-2.0.7.9-0.20111005005226.rhel5.x86_64.rpm -rwxr--r-- 1 root root 285426 Oct 5 15:21 mindi-busybox-1.18.5-0.20111005005226.rhel5.x86_64.rpm -rwxr--r-- 1 root root 4301 Oct 5 15:21 mindi-busybox-debuginfo-1.18.5-0.20111005005226.rhel5.x86_64.rpm -rwxr--r-- 1 root root 81934 Oct 5 15:21 mindi-debuginfo-2.0.7.9-0.20111005005226.rhel5.x86_64.rpm -rwxr--r-- 1 root root 1303397 Oct 5 15:21 mondo-2.2.9.8-0.20111005005226.rhel5.x86_64.rpm -rwxr--r-- 1 root root 1010911 Oct 5 15:21 mondo-debuginfo-2.2.9.8-0.20111005005226.rhel5.x86_64.rpm -rwxr--r-- 1 root root 186162 Oct 5 15:21 netperf-2.4.4-1.rhel5.x86_64.rpm

The initial problem, where I get the message about the sshfs file system not being mounted no longer appears. However, I can't seem to get to the point where the ISO image is being written to the sshfs mount. I encounter the a "hang" that I reported to the mailinglist recently. It appears that all of the mondo related processes just stop running.

comment:8 Changed 8 years ago by bruno

  • Resolution set to fixed
  • Status changed from assigned to closed

Ok, so this precise bug has been solved, I'll close it for now.

We will follow the other problem in a separate BR as it's more easy to find afterwards when subject and content are coherent.

Note: See TracTickets for help on using tickets.