SuSE 9.1 Backup in YAST
System: Stock 9.1 system in use, all updates applied, KDE 3.2.3 update done. I just tried to use the YAST System Backup program for the first time. I'm dumping the .tar file to an external SCSI HDD (mounts as /sda1) Backup has run through the entire process, there's now a 2.5 gig file sitting on /sda1. Problem seems to be that on the backup "Creating Archive" screen, it's "stuck" at the last step - "Write autoinstallation profile." It's been sitting at this view for about an hours and a half. No drive I/O is occurring. Anyone seen this before and know what to do to get it to complete? (About to say screw it and boot a knoppix disc and DD the drive image over to the external SCSI drive)
Steve, On Wednesday 11 August 2004 10:58, Steve Kratz wrote:
System: Stock 9.1 system in use, all updates applied, KDE 3.2.3 update done.
I just tried to use the YAST System Backup program for the first time. I'm dumping the .tar file to an external SCSI HDD (mounts as /sda1) Backup has run through the entire process, there's now a 2.5 gig file sitting on /sda1. Problem seems to be that on the backup "Creating Archive" screen, it's "stuck" at the last step - "Write autoinstallation profile." It's been sitting at this view for about an hours and a half. No drive I/O is occurring.
Anyone seen this before and know what to do to get it to complete? (About to say screw it and boot a knoppix disc and DD the drive image over to the external SCSI drive)
I experienced exactly the same symptom when I tried. Eventually I found the process that was stalled and killed it. The backup then apparently completed normally. At the time of the stall, the XML file (<backupName>.xml) had not been written, but once I killed the stalled process, the backup appeared to complete normally (and produced no diagnostic about the abnormal termination of one of its processes!). If you decide to try this, note that two processes are left running when the stall occurs. I believe it is the child between the two that I killed. Randall Schulz
How do you tell which process is stalled?
At the time of the stall, the XML file (<backupName>.xml) had not been written, but once I killed the stalled process, the backup appeared to complete normally (and produced no diagnostic about the abnormal termination of one of its processes!).
If you decide to try this, note that two processes are left running when the stall occurs. I believe it is the child between the two that I killed.
Thanks, but... How can you tell what's stalled? I know ps -A shows all processes... how do you tell from there? (Is there a "fix" for this other than killing processes? Seems like an important process like backing things up shouldn't hang :)
Steve, On Wednesday 11 August 2004 12:52, Steve Kratz wrote:
How do you tell which process is stalled?
At the time of the stall, the XML file (<backupName>.xml) had not been written, but once I killed the stalled process, the backup appeared to complete normally (and produced no diagnostic about the abnormal termination of one of its processes!).
If you decide to try this, note that two processes are left running when the stall occurs. I believe it is the child between the two that I killed.
Thanks, but...
How can you tell what's stalled? I know ps -A shows all processes... how do you tell from there?
(Is there a "fix" for this other than killing processes? Seems like an important process like backing things up shouldn't hang :)
I'm not recommending this approach, only reporting what happened for me. As for telling running from waiting processes... Here are two different lines of ps output, the first shows a waiting process, the second a running one: % ps l $$ F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 0 500 5460 5429 15 0 4320 2192 wait4 Ss pts/4 0:00 /bin/bash % ps lU rschulz |sed -n -e 1p -e '/ ps /p' F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 0 500 32170 5460 17 0 2168 668 - R+ pts/4 0:00 ps lU rschulz Note two things that differ between these two process listings (the first is sleeping, the second is running): 1) The 'R' (running) vs. 'S' (sleeping) characters in the STAT (status) column. 2) The '-' (hyphen) vs. a word (here "wait4") in the WCHAN (wait channel) column. Randall Schulz
The Wednesday 2004-08-11 at 14:52 -0500, Steve Kratz wrote:
How can you tell what's stalled? I know ps -A shows all processes... how do you tell from there?
try "ps afx|less" or something similar; you can see what process started which.
(Is there a "fix" for this other than killing processes? Seems like an important process like backing things up shouldn't hang :)
I don't like that backup program, except for the autoinstall file. -- Cheers, Carlos Robinson
Carlos, On Thursday 12 August 2004 15:36, Carlos E. R. wrote:
The Wednesday 2004-08-11 at 14:52 -0500, Steve Kratz wrote:
How can you tell what's stalled? I know ps -A shows all processes... how do you tell from there?
try "ps afx|less" or something similar; you can see what process started which.
Actually, process parent / child relationships are best seen with the "pstree" command. It can be invoked to show PIDs, to restrict output to processed bearing specific user IDs or which trace ancestry to such a process. The "pidof" command is handy, too, in conjunction with all the process-oriented commands, such as ps, kill, renice, etc. I so often want to do a ps for specifically named commands I created a script to combine pidof and ps.
...
I don't like that backup program, except for the autoinstall file.
So far, I'm nonplussed by all the Linux backup options. Retrospect kind of spoiled me.
-- Cheers, Carlos Robinson
Randall Schulz
* Randall R Schulz
The "pidof" command is handy, too, in conjunction with all the process-oriented commands, such as ps, kill, renice, etc. I so often want to do a ps for specifically named commands I created a script to combine pidof and ps.
and a handy script 'psfind' 'ps aux|grep -i $1' -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos
Patrick, On Thursday 12 August 2004 17:33, Patrick Shanahan wrote:
* Randall R Schulz
[08-12-04 19:20]: The "pidof" command is handy, too, in conjunction with all the process-oriented commands, such as ps, kill, renice, etc. I so often want to do a ps for specifically named commands I created a script to combine pidof and ps.
and a handy script 'psfind' 'ps aux|grep -i $1'
True, but the output of the pipeline includes the "grep" process itself. Another flaw is that it excludes the ps headers, which can make interpreting the output difficult, especially if you use the 'l' option. That can be overcome by using "sed" instead of grep: -==- #!/bin/bash --norc procPat="$1" ps aux |sed -n -e 1p -e "/$procPat/p" -==- But using "pidof" is still superior. You get no spurious responses, you get the ps headers and you don't need a pipeline with a filter that just discards unwaqnted ps output that is simply not produced at all using the pidof technique.
-- Patrick Shanahan
Randall Schulz
* Randall R Schulz
On Thursday 12 August 2004 17:33, Patrick Shanahan wrote:
and a handy script 'psfind' 'ps aux|grep -i $1'
True, but the output of the pipeline includes the "grep" process itself.
Another flaw is that it excludes the ps headers, which can make interpreting the output difficult, especially if you use the 'l' option. That can be overcome by using "sed" instead of grep:
-==- #!/bin/bash --norc
procPat="$1"
ps aux |sed -n -e 1p -e "/$procPat/p" -==-
which also yelds the calling process and the pipe process in addition to the headers
But using "pidof" is still superior. You get no spurious responses, you get the ps headers and you don't need a pipeline with a filter that just discards unwaqnted ps output that is simply not produced at all using the pidof technique.
I get no headers, only the process id ??? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos
Patrick, On Thursday 12 August 2004 20:00, Patrick Shanahan wrote:
* Randall R Schulz
[08-12-04 19:51]: On Thursday 12 August 2004 17:33, Patrick Shanahan wrote:
and a handy script 'psfind' 'ps aux|grep -i $1'
True, but the output of the pipeline includes the "grep" process itself.
Another flaw is that it excludes the ps headers, which can make interpreting the output difficult, especially if you use the 'l' option. That can be overcome by using "sed" instead of grep:
-==- #!/bin/bash --norc
procPat="$1"
ps aux |sed -n -e 1p -e "/$procPat/p" -==-
which also yelds the calling process and the pipe process in addition to the headers
As I said you would if you only grep to include the target pattern. You could try to add another grep that excludes the spurious hits produced by the simple pipelin, but why bother? The pidof approach obviates all that complexity.
But using "pidof" is still superior. You get no spurious responses, you get the ps headers and you don't need a pipeline with a filter that just discards unwaqnted ps output that is simply not produced at all using the pidof technique.
I get no headers, only the process id ???
That's what pidof does. It gives the _PID_ _of_ all the processes executing a program whose base name is an argument to the command. From there you can use the PID in other commands. See the script I posted earlier in this thread.
-- Patrick Shanahan
Randall Schulz
Hi, Here's the script I mentioned earlier. I call it "psp": -==- #!/bin/bash --norc while [ $# -gt 0 ]; do arg="$1" case "$arg" in -) shift break ;; -*) break ;; *) targets=( "${targets[@]}" "$arg" ) PIDs=( $(pidof "$arg") ) if [ ${#PIDs[*]} -eq 0 ]; then echo "psp: No process running named \"$arg\"" >&2 fi targetPIDs=( ${targetPIDs[*]} ${PIDs[@]} ) ;; esac shift done if [ ${#targetPIDs[*]} -eq 0 ]; then echo "psp: No target processes running" >&2 exit 1 fi ps "$@" ${targetPIDs[@]} -==- Sorry for the lack of a usage diagnostic. Here's a quick summary (there's not much to it, after all): Usage: psp programName [ ... ] [ - psOption [ ... ] ] Examples: % psp susewatcher suseplugger PID TTY STAT TIME COMMAND 5406 ? S 0:02 suseplugger -caption SUSE Hardware Tool -icon hi22-action-hardware.png -miniicon hi22-action-hardware.png --quiet 5410 ? S 0:02 susewatcher -caption SuSE Watcher -icon kinternet.png -miniicon kinternet.png --quiet % psp mozilla-bin PID TTY STAT TIME COMMAND 32671 ? S 2:03 /usr/local/mozilla/mozilla-bin % psp bash - w PID TTY STAT TIME COMMAND 1579 ? S 0:00 /bin/bash /sbin/hotplug pci 1613 ? S 0:00 /bin/bash /etc/hotplug/pci.agent pci 5448 pts/1 Ss+ 0:00 /bin/bash 5450 pts/2 Ss+ 0:00 /bin/bash 5454 pts/3 Ss 0:00 /bin/bash 5460 pts/4 Ss 0:01 /bin/bash 22810 pts/3 S+ 0:00 /bin/bash --norc /home/rschulz/bin/psp bash - w % psp java - lw F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 0 500 23156 5330 17 0 223880 85120 schedu S ? 0:02 /usr/lib/java/bin/java -mx32m -jar /usr/local/share/jedit/4.2pre14/jedit.jar % psp foo psp: No process running named "foo" psp: No target processes running And so on. Have fun! Randall Schulz
participants (4)
-
Carlos E. R.
-
Patrick Shanahan
-
Randall R Schulz
-
Steve Kratz