From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (Win98; U) Description of problem: I have been using the dump program to backup my root filesystem to a disk file. This is a technique I did nightly on my Redhat 6.2 system without problem. Now on Redhat 7.1 the dump of root routinely hangs at various points. I've seen the hang at 350Meg, 750Meg, and 1.1Gig. Yet I have also seen the dump run to completion. In each case where the hang occurs there are no messages produced and there is plenty of disk remaining. No further bytes are written to the output file. There is usually 1 parent dump process and 3 children shown in the process list, none of which using resources. Doing a "C" causes the dump process to prompt the user if the dump should really be terminated. Answering "yes" causes all processes to be cleaned up normally. I have allowed the dump to sit for as long as 1 1/2 days and it never completes. This failure occurs when the output file is on an internal disk filesystem (SCSI), or an external NFS filesystem. A fix would be greatly appreciated as this bug causes problems with automation and is a concern for our production environment. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. dump -0auf /mnt/root-full.dump -L "FULL`date +%Y-%m-%d`" / 2. wait for failure 3.occurs about 75% of the time. Actual Results: The following output is produced: DUMP: Date of this level 0 dump: Wed Jan 16 09:50:03 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/sda1 (/) to /mnt/root-full.dump DUMP: Label: FULL2002-01-16 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 1109835 tape blocks. DUMP: Volume 1 started at: Wed Jan 16 09:50:04 2002 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] The output file continues to grow for a while and then stops. Little to no CPU is used by the dump processes. I've let it sit for up to 1.5 days with no additional bytes posted to the output file. A <cntrl>C will issue prompt and ask if I'm sure I want to kill the dump. Expected Results: Instead of a hang, the following additional messages should be issued upon completion: DUMP: 100.00% done at 3822 KB/s, finished in 0:00 DUMP: Closing /mnt/root-full.dump DUMP: Volume 1 completed at: Wed Jan 16 09:55:23 2002 DUMP: Volume 1 took 0:05:19 DUMP: Volume 1 transfer rate: 3804 KB/s DUMP: 1213695 tape blocks (1185.25MB) on 1 volume(s) DUMP: finished in 319 seconds, throughput 3804 KBytes/sec DUMP: level 0 dump on Wed Jan 16 09:50:03 2002 DUMP: Date of this level 0 dump: Wed Jan 16 09:50:03 2002 DUMP: Date this dump completed: Wed Jan 16 09:55:23 2002 DUMP: Average transfer rate: 3804 KB/s DUMP: DUMP IS DONE Additional info: Here, Redhat 7.1 is running on an IBM x330 Server with dual Pentium 3 - 1 Gigahertz processors, 1 gig ram, dual 9 gig internal disk (Raid mirror) where the OS runs. Kernel is 2.4.9-12smp. Dump program shows version 0.4b21-3.
Please upgrade your kernel to the latest officially releaased Red Hat kernel, and dump to the current dump release for 7.1: dump-0.4b21-5 Both are important. Do you still encounter this problem after upgrading?
I am already running kernel 2.4.9-12smp. This system is also registered via "up2date". The up2date mechanism shows no new kernels and does not show the "-5" dump version you suggest. I'll check the mirror sites, but please forward additional information on how to get these packages. I'll post an update if I have any luck on my own.
My registered up2date system name is webct1.csus.edu.
I've checked the redhat site and 2 mirror sites. No new dump versions have been posted and the kernel I mentioned earlier is the only newer one released. If you have a way to get me dump-0.4b21-5 let me know.
I think this is related to a larger problem. See #58747 or TicketManager #198533.
This bug is the same one as in bug #56616, which was fixed in dump-0.4b25, available from RedHat Rawhide or dump's home page (dump.sourceforge.net). Stelian.
*** This bug has been marked as a duplicate of 56616 ***