[Bug 730193] New: shutdown/poweroff/reboot hangs when using sysvinit
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c0 Summary: shutdown/poweroff/reboot hangs when using sysvinit Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: VMWare OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: d.a.van.delft@gmail.com QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; nl; rv:1.9.2.23) Gecko/20110920 SUSE/3.6.23-0.2.1 Firefox/3.6.23 It works OK when in systemd mode. When it hangs, switching between VT's still work, but they are unusable: cannot log in, or see what's going on. Reproducible: Always Steps to Reproduce: 1. install sysvinit-init 2. for good measure, reboot at least once to have it run on sysvinit 3. as root either shutdown, reboot of poweroff Actual Results: Starts shutdown sequence. Usually hangs after console message: Shutting down service (localfs) network . . . . . . done But sometimes others as well. When it hangs, the CPU usage goes to 100%, as can be seen on the vmware host. Expected Results: an actual shutdown/poweroff or reboot I can only reproduce this on two VMWare vm's, running on vmware server 2 and VSphere. A hardware computer works OK. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c zj jia <zjjia@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zjjia@suse.com AssignedTo|bnc-team-screening@forge.pr |werner@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c1 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |d.a.van.delft@gmail.com --- Comment #1 from Dr. Werner Fink <werner@suse.com> 2011-11-15 08:57:59 UTC --- And which process does consume the 100% CPU usage -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c2 Danny van Delft <d.a.van.delft@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|d.a.van.delft@gmail.com | --- Comment #2 from Danny van Delft <d.a.van.delft@gmail.com> 2011-11-15 09:38:42 UTC --- I wish I knew, but can't determine. I tried with running a top first on another VT than the one I initiate the reboot. Although I could switch back to the VT with top, it gave no usable output at the hang. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c3 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |d.a.van.delft@gmail.com --- Comment #3 from Dr. Werner Fink <werner@suse.com> 2011-11-15 10:11:33 UTC --- OK ... other question: does this happen before or after /sbin/halt or /sbin/reboot has been called by the script /etc/init.d/halt or /etc/init.d/reboot (a link to /etc/init.d/halt) ... in other words is the load caused by a program in the user space or by the kernel of the VM due the reboot/halt magic sequence used by /sbin/halt or /sbin/reboot. You may add two lines before # Now talk to kernel exec $command -d -f -n $opts in /etc/init.d/halt like typeset -i n=60 while ((n-- > 0)); do ps axsHS; ps axHXS; ps axuHS; sleep 1 ; done maybe we see something within the 60 seconds. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c4 Danny van Delft <d.a.van.delft@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|d.a.van.delft@gmail.com | --- Comment #4 from Danny van Delft <d.a.van.delft@gmail.com> 2011-11-15 10:56:42 UTC --- Gives no output whatsoever, even if explicitly stdout redirected to /dev/tty10. Looks like this place is not reached during halt. I've done some other experimenting, by enabling sysrq. Probably due to keyboard issues in combination with vmware, I can't trigger the sysrq from the keyboard, but with something like while : ; do echo t > /proc/sysrq-trigger;usleep 100000;done at least some output appears on tty10. Helas, at the moment of the hang, the net result is only the header, like .. SysRq : Show State is shown. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c5 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |d.a.van.delft@gmail.com --- Comment #5 from Dr. Werner Fink <werner@suse.com> 2011-11-15 11:08:53 UTC --- Hmmm ... or the redirect to /dev/console results in invisible output. Now try to add set -x after the line set +e in /etc/init.d/halt ... let us see what happens upto the very last message -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c6 Danny van Delft <d.a.van.delft@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|d.a.van.delft@gmail.com | --- Comment #6 from Danny van Delft <d.a.van.delft@gmail.com> 2011-11-15 11:17:59 UTC --- Hold on, something interesting. If booted with kernel-default (i.s.o. kernel-desktop), the same hang occurs at shutdown, but at least your ps lines in /etc/init.d/halt give some output after a while. Initially it looks as if the machine hangs at the same point, with the high CPU usage, but after a couple of seconds the ps output appears. After the ps loop of 60s output stops, the machine reboots. So the problem only occurs with kernel-desktop, even though with kernel-default it still has a period of high CPU-activity. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c7 --- Comment #7 from Danny van Delft <d.a.van.delft@gmail.com> 2011-11-15 11:21:54 UTC --- (In reply to comment #5)
Hmmm ... or the redirect to /dev/console results in invisible output. Now try to add
set -x
after the line
set +e
in /etc/init.d/halt ... let us see what happens upto the very last message
OK, did that with kernel-desktop. Last lines of output: Running /etc/init.d/halt.local + /bin/sh /etc/init.d/halt.local after which nothing more appears. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c8 --- Comment #8 from Danny van Delft <d.a.van.delft@gmail.com> 2011-11-15 11:28:10 UTC --- (In reply to comment #5)
Hmmm ... or the redirect to /dev/console results in invisible output. Now try to add
set -x
after the line
set +e
in /etc/init.d/halt ... let us see what happens upto the very last message
Done the same with kernel-default, now different output appears. Looks like another codepath, which succeeds, is taken in comparison to kernel-desktop. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c9 --- Comment #9 from Dr. Werner Fink <werner@suse.com> 2011-11-15 12:30:21 UTC --- Guess: /etc/init.d/halt.local is empty ... right? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c10 --- Comment #10 from Danny van Delft <d.a.van.delft@gmail.com> 2011-11-15 12:41:10 UTC --- Yes, apart from comments /etc/init.d/halt.local is empty. In addition to comment 7 above, sometimes the shutdown does show some output from /etc/init.d/halt. However, it has never shutdown completely, as it does do when using kernel-default. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c11 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium CC| |werner@suse.com Component|Basesystem |Kernel AssignedTo|werner@suse.com |kernel-maintainers@forge.pr | |ovo.novell.com --- Comment #11 from Dr. Werner Fink <werner@suse.com> 2011-11-15 12:52:03 UTC --- Maybe the desktop kernel is not usable for an VM, nevertheless this seems to be more like a kernel bug for me. Could be triggered by the magic sequences used by /sbin/halt or /sbin/reboot and defined at /usr/include/sys/reboot.h -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c12 --- Comment #12 from Danny van Delft <d.a.van.delft@gmail.com> 2011-11-15 15:00:44 UTC --- Could be that desktop-kernel is not usable for a VM. However when running under systemd shutdown goes well, even with kernel-desktop. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c13 --- Comment #13 from Dr. Werner Fink <werner@suse.com> 2011-11-15 15:11:03 UTC --- There are differences between the reboot/halt used by systemd and sysvinit. It looks like the later may overstrain the desktop kernel. And a IMHO a simple user space tool should not can do this -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c14 --- Comment #14 from Danny van Delft <d.a.van.delft@gmail.com> 2011-11-15 16:21:24 UTC --- FYI, I tried the following: on a VT: sleep 60 ; echo e > /proc/sysrq-trigger ; sleep 10 ; echo i > /proc/sysrq-trigger ; sleep 10 ; echo b > /proc/sysrq-trigger on another V: reboot The system hung as "expected", but at least on the first VT the last echo did its work: the system rebooted. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c15 Lars Müller <lmuelle@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lmuelle@suse.com, | |lnussel@suse.com --- Comment #15 from Lars Müller <lmuelle@suse.com> 2011-12-04 16:49:31 CET --- I see the same behavior while using sysvinit-init While it works with systemd-sysvinit I had a conversation about this with Ludwig and he suggested to start an additional shell on console 9 before calling to reboot openvt -c 9 /bin/bash - By this I had been able to notice a very, very slow system. Even switching the virtual terminal took several seconds. Also typing commands in the open console at tty9 took quite some time. At the top of the list a saw blogd consuming 100% of the CPU. In the list of processes show by ps I saw a call to vgchnage. It looks like this is blocking the reboot process. I'm going to attach this output next. As next step I disabled the boot.lvm service as this script was in the ps output I checked. By this the reboot process took 20 up to 25 seconds. Here I saw the halt.local script been executed before the 20/25 seconds delay. In the next step I booted the system with an anabled boot.lvm service and also mounted two volumes. Before I called reboot I started a script to count the time till the reboot happens. This time it took 44 seconds. Without the script running, without an open console on tty9, but with enabled boot.lvm service the reboot process again took a long time. Enough to grab a coffee in the kitchen and return and see the system booting. As slow and lazy as I'm I guess this took five minutes. I've added a call to ps xauf to the script and openend a console on tty9 again. With the next call to reboot I saw as last output "Shutting down (localfs) network . . . . . ". And this time not the output from the halt.local script. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c16 --- Comment #16 from Lars Müller <lmuelle@suse.com> 2011-12-04 16:54:52 CET --- Created an attachment (id=465781) --> (http://bugzilla.novell.com/attachment.cgi?id=465781) Output of the script started before calling reboot The script called this commands: #!/bin/bash test -e reboot_counter && \ mv reboot_counter reboot_counter.old reboot_counter=0 while [ 1 ]; do reboot_counter=$((reboot_counter+1)) echo -e "\nCOUNTER: ${reboot_counter}" >>reboot_counter ps xuaf >>reboot_counter sleep 1 done -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c17 --- Comment #17 from Lars Müller <lmuelle@suse.com> 2011-12-04 17:22:27 CET --- Next I tested to add quiet to /boot/grub/menu.lst From kernel /vmlinuz-3.1.0-1.2-default root=/dev/disk/by-id/scsi-3500507620cc40a5b-part2 console=tty0 console=ttyS0,38400n8 to kernel /vmlinuz-3.1.0-1.2-default root=/dev/disk/by-id/scsi-3500507620cc40a5b-part2 quiet console=tty0 console=ttyS0,38400n8 which made no difference. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c18 --- Comment #18 from Lars Müller <lmuelle@suse.com> 2011-12-04 17:27:27 CET --- The reboot took 331 seconds. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c19 --- Comment #19 from Lars Müller <lmuelle@suse.com> 2011-12-04 17:34:26 CET --- Created an attachment (id=465784) --> (http://bugzilla.novell.com/attachment.cgi?id=465784) /sbin/blogd being a sym link to /bin/true and the boot process takes 16 seconds -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c20 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |lmuelle@suse.com --- Comment #20 from Dr. Werner Fink <werner@suse.com> 2011-12-05 08:00:19 UTC --- Guess: kernel 3.0 and higher cause trouble with blogd ... check how large/huge /var/log/boot.msg and /var/log/boot.omsg are. Also an strace of blogd would be interesting -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c22 --- Comment #22 from Lars Müller <lmuelle@suse.com> 2011-12-05 20:12:27 CET --- lisa:~ # ls -l /var/log/boot.{,o}msg -rw-r--r-- 1 root root 80546 5. Dez 20:09 /var/log/boot.msg -rw-r--r-- 1 root root 86297 4. Dez 19:36 /var/log/boot.omsg -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c23 Lars Müller <lmuelle@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|lmuelle@suse.com | --- Comment #23 from Lars Müller <lmuelle@suse.com> 2011-12-05 20:35:49 CET --- Created an attachment (id=465956) --> (http://bugzilla.novell.com/attachment.cgi?id=465956) strace of blogd while reboot -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c24 --- Comment #24 from Dr. Werner Fink <werner@suse.com> 2011-12-06 09:11:45 UTC --- Hmmm ... I see write(8, "Running /etc/init.d/halt.local\n."..., 37) = 37 ioctl(8, TCSBRK, 0x1) = 0 ioctl(0, TCSBRK, 0x1) = 0 pselect6(5, [0 4], NULL, NULL, {0, 25000000}, {~[QUIT TERM IO SYS RTMIN], 8}) = 0 (Timeout) ioctl(0, TCSBRK, 0x1) = 0 futex(0x60aae8, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted) --- {si_signo=SIGCONT, si_code=SI_USER, si_pid=6130, si_uid=0} (Continued) --- futex(0x60aae8, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...> and I guess that blogd or better the futex used by the glibc does not return. Please report how fast the last few messages occur and tell me how long this takes in comparision to the final reboot its self. In other words how long does it take for the message Running /etc/init.d/halt.local in comparison with and without blogd. The next is that the strace shows: ioctl(3, TCSBRK, 0x1) = -1 EINTR (Interrupted system call) --- {si_signo=SIGSYS, si_code=SI_USER, si_pid=6069, si_uid=0} (Bad system call) --- rt_sigreturn(0x1f) = -1 EINTR (Interrupted system call) that is that SIGSYS signal handler seems to have a problem and this signal is used for stop writing to disk but continue to repeat messages. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c25 --- Comment #25 from Lars Müller <lmuelle@suse.com> 2011-12-06 11:40:20 CET --- The final message got displayed very quickly. In about 10 up to 15 seconds after I called to reboot. By reading the reported output again I noticed a difference I saw between different monitored reboots. Sometimes I did not saw the 'Running /etc/init.d/halt.local' output. I guess it got delayed too. But it might also never got printed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c26 Lars Müller <lmuelle@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kernel-maintainers@forge.pr |werner@suse.com |ovo.novell.com | --- Comment #26 from Lars Müller <lmuelle@suse.com> 2012-03-01 01:31:01 CET --- I believe this is something we have to fix in sysvinit. Therefore reassigning it to Werner. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c27 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |lmuelle@suse.com --- Comment #27 from Dr. Werner Fink <werner@suse.com> 2012-03-01 08:49:50 UTC --- (In reply to comment #26) Lars? Why do you think this? A syou can see from my comment #24 this is a kernel bug. Or why does this never happen with a none VM system? I've several systems around here using SysVinit on 12.1 and those systems do *not* hang. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c28 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aj@suse.com, jeffm@suse.com --- Comment #28 from Dr. Werner Fink <werner@suse.com> 2012-03-01 08:52:48 UTC --- Also I'd like to know why from the kernel people or the glibc people there was no responce on this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c29 Andreas Jaeger <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matz@suse.com --- Comment #29 from Andreas Jaeger <aj@suse.com> 2012-03-01 09:23:50 UTC --- Michael, could you have a look as well, please? Werner, you might want to ask on the kernel list for help. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c30 --- Comment #30 from Dr. Werner Fink <werner@suse.com> 2012-03-01 09:52:44 UTC --- Just for sure: does this happen with current sysvinit of factory, simply as there are bug fixes for two other bugs. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c31 Michael Matz <matz@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Critical --- Comment #31 from Michael Matz <matz@suse.com> 2012-03-01 14:52:11 UTC --- blogd is multithreaded, hence the above strace doesn't reveal much information as it contains only info from the main thread. Please do the strace again, this time with -f (and if you are at it also with -tt). With the information herein we can't blame the kernel or glibc. In particular we can't rule out that blogd doesn't simply contain a dead lock situation, that is only triggered under VMs (for whatever reasons, timing or otherwise). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c32 --- Comment #32 from Lars Müller <lmuelle@suse.com> 2012-03-02 12:45:03 CET --- (In reply to comment #27)
(In reply to comment #26)
Lars? Why do you think this?
As it works with systemd. Therefore I strongly believe this is something caused by sysvinit. Well, you raised the right question. This is nothing I can prove. All I did is guessing from the symptoms. Therefore I think the best is we close this issue and forget about it? No, we have to track it down to the roots. And here the trouble starts. The system in question is in a data center. Where I don't have access at any time. Therefor we need to script something which does the same as described in comment 15. Unfortunately I don't have the time to do this at the moment.
A syou can see from my comment #24 this is a kernel bug. Or why does this never happen with a none VM system?
This is not a virtual machine. Or does your VM reference to something else?
I've several systems around here using SysVinit on 12.1 and those systems do *not* hang.
I also tested this on three other native 12.1 systems. Both are x86_64 too And on both I'm also not able to cause the same issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c33 Lars Müller <lmuelle@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|lmuelle@suse.com | --- Comment #33 from Lars Müller <lmuelle@suse.com> 2012-03-02 12:47:27 CET --- Remove need info till I got the information how to collect the data even on a remote system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c34 Matthias Pfafferodt <syntron@web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |syntron@web.de --- Comment #34 from Matthias Pfafferodt <syntron@web.de> 2012-03-03 15:38:54 UTC --- I observe similar problems; I'm running several vm's using xen (paravirt). At shutdown they hang at the same point. Booting is done with sysv. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c35 --- Comment #35 from Matthias Pfafferodt <syntron@web.de> 2012-03-03 15:43:48 UTC --- The vm's do not hang if the shutdown is done directly after they were started. But if I do an update and reboot them after several days of operation it happens. Kernel is after today 3.2.9-12-xen (from tumbleweed). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c36 Lars Müller <lmuelle@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |syntron@web.de --- Comment #36 from Lars Müller <lmuelle@suse.com> 2012-03-27 19:56:04 CEST --- Markus Heinze <max@freecards.de> and Hugo Egon Maurer <hugomaurer@gmx.de> both had been faced by the same issue and unfortunately had been unable till now to feed bugzilla with the information requested with comment #31 Cf. http://lists.openSUSE.org/archive/opensuse-de/2012-03/msg00448.html @Matthias: Can you please use strace with the additional parameter -tt as suggested by Michael with comment #31. Comment #15 describes how you open a tty without login and which also doesn't get closed when you request the reboot. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c37 --- Comment #37 from Matthias Pfafferodt <syntron@web.de> 2012-03-27 18:58:09 UTC --- I did reboot the VMs today and could not reproduce this. I will check this again if another reboot is needed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c38 --- Comment #38 from Matthias Pfafferodt <syntron@web.de> 2012-05-05 22:54:48 UTC --- I did shutdown my server today and it waits now on localfs for > 5 minutes. The server is on bare metal; up to date tumbleweed. I will try to get the requested data from the system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c39 Matthias Pfafferodt <syntron@web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|syntron@web.de | --- Comment #39 from Matthias Pfafferodt <syntron@web.de> 2012-05-06 20:35:21 UTC --- I found a way to reproduce this bug: - start a computer with an nfs mount (I also have yp and autofs) - start the script 'nfs.sh' _on_ the nfs mount (I suspect it creates open file handles) - start the script 'nohup.sh' which calls 'blogd.sh' which calls strace on blogd on a real hard drive to create the log file - shutdown the computer and wait :-( As said above, I suspect open file handles on the nfs mount which case something like an endless loop Two examples of the strace output are attached. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c40 --- Comment #40 from Matthias Pfafferodt <syntron@web.de> 2012-05-06 20:41:23 UTC --- Created an attachment (id=489695) --> (http://bugzilla.novell.com/attachment.cgi?id=489695) script to create open file handles on nfs mount -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c41 --- Comment #41 from Matthias Pfafferodt <syntron@web.de> 2012-05-06 20:41:58 UTC --- Created an attachment (id=489696) --> (http://bugzilla.novell.com/attachment.cgi?id=489696) start the script blogd.sh with nohup -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c42 --- Comment #42 from Matthias Pfafferodt <syntron@web.de> 2012-05-06 20:58:01 UTC --- Created an attachment (id=489697) --> (http://bugzilla.novell.com/attachment.cgi?id=489697) script to strace blogd -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c43 --- Comment #43 from Matthias Pfafferodt <syntron@web.de> 2012-05-06 20:59:12 UTC --- Created an attachment (id=489698) --> (http://bugzilla.novell.com/attachment.cgi?id=489698) strace (run 1) the last two lines are repeated till I hard reset the computer -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c44 --- Comment #44 from Matthias Pfafferodt <syntron@web.de> 2012-05-06 20:59:39 UTC --- Created an attachment (id=489699) --> (http://bugzilla.novell.com/attachment.cgi?id=489699) strace (run 2) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c45 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |syntron@web.de --- Comment #45 from Dr. Werner Fink <werner@suse.com> 2012-05-07 07:12:37 UTC --- (In reply to comment #39) For NFS shares as well as for any other network based shared filessystem: If the server of such an share is not reachable then any system call like e.g. stat(2) will run into a deadlock. I've added a lot of workarounds in the last few years to avoid system call calls like stat(2) but even by using readlink(2): if the kernel does not have any information cached it will ask the server of the share and this also lead to a deadlock. This has nothing todo with sysvinit its self. It may depend on the execution order at shuthdown (that is that all network connections should go down *after* the the network based share is unmounted). That is you should check the dependcy order of the boot scripts and enforece that any process on or with the network based shares are stopped *before* the network for those shares will switched off. The last loop you are seeing from the blogd in your strace logs are simply a waiting blogd for more input on /dev/console but it will wait a long time if nothing happens on /dev/console due to a system call waiting on a not eachable server of a network based share. IMHO the initial report does not mention a network based share. That is your report does not belong to this bug, does it? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c46 Danny van Delft <d.a.van.delft@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|syntron@web.de | --- Comment #46 from Danny van Delft <d.a.van.delft@gmail.com> 2012-05-07 10:44:32 UTC --- Not sure the needinfo is directed at me, but my system indeed does not use nfs, samba or any other network based fs, so comment 39 doesn't seem to be the root cause. Using the trick in comment 15 and running a top, I also see the blogd looping at nearly 100% CPU. Killing it from within top with signal 9 (tried first 15, 3, 1) "helped" the system to completion of the shutdown sequence. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c47 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |d.a.van.delft@gmail.com --- Comment #47 from Dr. Werner Fink <werner@suse.com> 2012-05-07 11:54:21 UTC --- (In reply to comment #46) Please try out an update to latest sysvinit done for factory. It could be that you see a duplicate of bug #731563 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c48 Danny van Delft <d.a.van.delft@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|d.a.van.delft@gmail.com | --- Comment #48 from Danny van Delft <d.a.van.delft@gmail.com> 2012-05-07 12:37:00 UTC --- No idea what bug #731563 is, apparently I'm not authorized to see it. Anyway, I've updated sysvinit to factory, along with a couple of other by this version of sysvinit required updates: sysvinit-2.88+-74.2 Mon May 7 14:22:48 2012 glibc-extra-2.15-17.1 Mon May 7 14:22:48 2012 glibc-locale-2.15-17.1 Mon May 7 14:22:46 2012 glibc-2.15-17.1 Mon May 7 14:22:31 2012 Unfortunately no change, still hangs at poweroff. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c49 --- Comment #49 from Jeff Mahoney <jeffm@suse.com> 2012-05-07 09:21:03 EDT --- (In reply to comment #45)
(In reply to comment #39)
For NFS shares as well as for any other network based shared filessystem:
If the server of such an share is not reachable then any system call like e.g. stat(2) will run into a deadlock. I've added a lot of workarounds in the last few years to avoid system call calls like stat(2) but even by using readlink(2): if the kernel does not have any information cached it will ask the server of the share and this also lead to a deadlock.
To be fair, this isn't an actual deadlock. It's a network dependency that will be met when the server comes back. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c50 --- Comment #50 from Danny van Delft <d.a.van.delft@gmail.com> 2012-05-07 13:31:11 UTC --- Created an attachment (id=489775) --> (http://bugzilla.novell.com/attachment.cgi?id=489775) blogd strace output, with -tt and -f options Created with LANG=C exec strace -f -tt -o /tmp/blogd.$(date +%Y%m%d%H%M%S).strace /sbin/blogd.dist "$@" in /sbin/blogd, original blogd mv'd to blogd.dist -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c51 --- Comment #51 from Matthias Pfafferodt <syntron@web.de> 2012-05-07 19:36:39 UTC --- (In reply to comment #45)
(In reply to comment #39)
For NFS shares as well as for any other network based shared filessystem:
If the server of such an share is not reachable then any system call like e.g. stat(2) will run into a deadlock. I've added a lot of workarounds in the last few years to avoid system call calls like stat(2) but even by using readlink(2): if the kernel does not have any information cached it will ask the server of the share and this also lead to a deadlock.
This has nothing todo with sysvinit its self. It may depend on the execution order at shuthdown (that is that all network connections should go down *after* the the network based share is unmounted). That is you should check the dependcy order of the boot scripts and enforece that any process on or with the network based shares are stopped *before* the network for those shares will switched off.
This means that using nfs mounted home (nis and autofs) I will have to ensure that all processes accessing the nfs share are killed before doing a shutdown? The server was online at the time of the shutdown so this is not the reason. Thus, the order of the shutdown scripts should be changed? I have to say, that I do not understand how the boot scripts network-remotefs and network interact.
IMHO the initial report does not mention a network based share. That is your report does not belong to this bug, does it?
Yes, my last report does depend on using an nfs share and also in my first post all linux instances used to have an nfs share mounted. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c52 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mt@suse.com --- Comment #52 from Dr. Werner Fink <werner@suse.com> 2012-05-08 07:42:23 UTC --- (In reply to comment #51) That is how it works. Indeed I've added a lot patches (partly upstream) for e.g. sysvinit, procps, and psmisc (fuser) to switch from device/inode comparision over to string comparision for binary files if a network based share is used or becomes part of the process search tree. Nevertheless this requires the readlink(2) system call. This works as long as readlink(2) is able to determine the final target of /proc/<pid>/exec otherwise it will also stay in a deadlock at shutdown if the network use dfor the share is shut down before the share its self. Unfortunately there is now way to determine the internal inode used the kernel for binary files or any other files located on a network based share. To avoid this the network interfaces will be filtered in /etc/init.d/network used or not used for e.g. NFS shares. The script /etc/init.d/network-remotefs if simply a wrapper to start the main script with the appropiate options. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c53 --- Comment #53 from Marius Tomaschewski <mt@suse.com> 2012-05-08 12:48:24 UTC --- About network & network-remotefs -- the start is as follows: network -- base networking, without ppp, wlan, (NM, ) ... nfs & smb -- network filesystems on top of (base) network network-remotefs -- rest of the network stuff that may be on nfs-/usr including NetworkMananger (sysvinit only) <remotefs depending services> the stop is another way around. So when <remotefs depending services> dependencies are correct and the programs are stopped/cleaned up correctly (e.g. desktop services, dbus servers, ...) the shutdown should work fine... You can try to set some of these variables: $ grep ^CONNECTION /etc/sysconfig/network/config CONNECTION_SHOW_WHEN_IFSTATUS="no" CONNECTION_CHECK_BEFORE_IFDOWN="no" CONNECTION_CLOSE_BEFORE_IFDOWN="no" CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN="no" CONNECTION_SEND_KILL_SIGNAL="no" (In reply to comment #51)
This means that using nfs mounted home (nis and autofs) I will have to ensure that all processes accessing the nfs share are killed before doing a shutdown?
Not exactly you, but the nfs/autofs/remomte-fs-depending... service scripts. So the question is, what is still running at the time nfs and network go down. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c54 --- Comment #54 from Danny van Delft <d.a.van.delft@gmail.com> 2012-05-08 15:11:16 UTC --- Perhaps a clue, triggered by the last sentence of comment 53. Short version, if I manually umount /dev/pts beforehand, the shutdown works fine. Long version: I noticed that at moment of hang (looping blogd), an umount -t tmpfs /media was in progress (initiated by boot.localfs stop) and not going anywhere. After I killed the controlling bash process, the shutdown continued. Then I tried different permutations of manual umounts (the /media in itself didn't help), after seeing that an umount -a also did the trick and finally arrived at /dev/pts. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c55 --- Comment #55 from Ludwig Nussel <lnussel@suse.com> 2012-06-21 09:31:00 CEST --- deadlock in blogd. One thread called pthread_yield() in a loop with a lock held while the main thread tried to acquire the lock to cancel the thread. You may want to test the fix in home:lnussel:branches:openSUSE:12.1:Update/sysvinit -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c56 --- Comment #56 from Danny van Delft <d.a.van.delft@gmail.com> 2012-06-21 10:54:11 UTC --- I don't see a sysvinit in http://download.opensuse.org/repositories/home:/lnussel:/branches:/openSUSE:... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c57 --- Comment #57 from Ludwig Nussel <lnussel@suse.com> 2012-06-21 13:29:02 CEST --- it got turned into a maintenance update already, it's now staged in openSUSE:Maintenance:567 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c58 --- Comment #58 from Danny van Delft <d.a.van.delft@gmail.com> 2012-06-21 11:50:34 UTC --- Yep, that did the trick. Installed the fix, reboot/poweroff doesn't hang anymore. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c59 Bernhard Wiedemann <bwiedemann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwiedemann@suse.com --- Comment #59 from Bernhard Wiedemann <bwiedemann@suse.com> 2012-06-24 19:21:06 CEST --- I have seen the same sysvinit / blogd hang in Beta 2 / Factory today, so the fix will be needed there and for 12.2, too. And I found that omitting "killproc -SYS /sbin/blogd" in /etc/init.d/rc also helped. I guess this is one of those scripts that are ignored by systemd which explains why it does not hang there. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c60 --- Comment #60 from Benjamin Brunner <bbrunner@suse.com> 2012-06-25 10:47:21 CEST --- Update released for 12.1. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c61 --- Comment #61 from Bernhard Wiedemann <bwiedemann@suse.com> 2012-06-25 11:00:10 CEST --- This is an autogenerated message for OBS integration: This bug (730193) was mentioned in https://build.opensuse.org/request/show/125924 Factory / sysvinit -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c62 --- Comment #62 from Swamp Workflow Management <swamp@suse.de> 2012-06-25 09:08:58 UTC --- openSUSE-RU-2012:0784-1: An update that has one recommended fix can now be installed. Category: recommended (low) Bug References: 730193 CVE References: Sources used: openSUSE 12.1 (src): sysvinit-2.88+-66.61.1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c63 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard| |maint:released:sle11-sp2:48 | |038 --- Comment #63 from Swamp Workflow Management <swamp@suse.de> 2012-06-26 20:03:34 UTC --- Update released for: sysvinit, sysvinit-debuginfo, sysvinit-debugsource Products: SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11-SP2 (i386, x86_64) SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP2 (i386, x86_64) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=730193 https://bugzilla.novell.com/show_bug.cgi?id=730193#c64 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #64 from Ludwig Nussel <lnussel@suse.com> 2012-07-05 11:18:39 CEST --- closing as fixed -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com