|Summary:||dump fails with remote backups|
|Product:||[Retired] Red Hat Linux||Reporter:||willem.schreuder|
|Component:||dump||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED NEXTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-08-01 08:55:38 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description willem.schreuder 1999-06-04 17:37:26 UTC
Local backups work, but remote backups fail. Consider the output from the command run on host mowgli, doing a remote backup to itself: [The outcome is the same when doing this between different hosts] /sbin/dump 0f mowgli:/dev/st1 / DUMP: Date of this level 0 dump: Wed Jun 2 12:03:14 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/sda1 (/) to /dev/st1 on host mowgli DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 62627 tape blocks on 1.61 tape(s). /sbin/dump: Lost connection to remote host. DUMP: Bad return code from dump: 1 The problem turns out to be that dump tries to invoke /sbin/rmt as rmt, but does not find it because /sbin is not in the default path. dump envokes rmt using an rcmd call [dumprmt.c line159]. The argument of the remote program to run is set in compat/include/pathnames.h line 49 as #define _PATH_RMT "rmt" The problem is that the rmt program /sbin/rmt is NOT in the default path, and so dump connects to a program that does not exist. Unfortunately, the rcmd call does not fail, nor does the first write to the pipe opened by the rcmd call. The first error is encountered when trying to read the reply from the first write (which is the command to instruct rmt to open the specified device file). This leads to the very misleading error message "lost connection" shown above. Multiple solutions are possible. 1) _PATH_RMT can be defined to be "/etc/rmt" instead of "rmt". This is the solution used by tar-1.12 to find rmt. On all the hosts I checked this appears to be a symbolic link to the real location of rmt [HP-UX, SunOS, Solaris, Linux/Redhat, Linux/Debian]. The only exception I found was AIX, and that is just a weird OS anyway. I figure if it is good enough for tar, it is good enough for me. 2) Change the default path to include /sbin. This way rcmd will find rmt OK. This does not appear to be a good idea since it could have a bunch of side effects. 3) Link /sbin/rmt to /bin/rmt or move rmt to the /bin. This appears to be a good solution but since the /etc/rmt link is already required for tar, this seems to be a proliferation of links that is unnecessary. Any of the above solutions solve the problem, and you could probably find better ones, but #1 appears to be the preferred solution. Here is a patch file: --------------------------------------------------------- --- dump-0.4b4/compat/include/pathnames.h.0 +++ dump-0.4b4/compat/include/pathnames.h @@ -46,4 +46,4 @@ #define _PATH_DTMP "/etc/dtmp" #define _PATH_DUMPDATES "/etc/dumpdates" #define _PATH_LOCK "/tmp/dumplockXXXXXX" -#define _PATH_RMT "rmt" +#define _PATH_RMT "/etc/rmt" --------------------------------------------------------- It is probably worth adding to the dump docs that the /etc/rmt link is needed so that if the remote host is AIX or something weird that there is a pointer However, I am concerned that there is a problem somewhere in the rcmd code that should report the failure earlier on and somehow does not, leading to the misleading error message. This is probably worth investigating.
Comment 1 Jeff Johnson 1999-07-31 22:56:59 UTC
*** This bug has been marked as a duplicate of 4281 ***
Comment 2 Jeff Johnson 1999-08-01 08:55:59 UTC
Fixed (by compiling in /etc/rmt) in dump-0.4b4-9. Thanks for the analysis.