https://bugzilla.novell.com/show_bug.cgi?id=865188 https://bugzilla.novell.com/show_bug.cgi?id=865188#c Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |systemd-maintainers@suse.de |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=865188 https://bugzilla.novell.com/show_bug.cgi?id=865188#c2 Yarny Yarny changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|Yarny@public-files.de | --- Comment #2 from Yarny Yarny 2014-02-22 23:23:42 UTC --- Created an attachment (id=579654) --> (http://bugzilla.novell.com/attachment.cgi?id=579654) setup script which (occasionally) triggers the bug

What is the reason of using a `script' to `issues' some systemctl commands the most services ... ?! The script runs on a freshly installed openSUSE and installs/configures some services which I need on my machines. I'm using VirtualBox to test the script before using it on production systems.

Why do you not use the normal way that is you enable your required services and the set your default target like systemctl set-default graphical.target Hmm, what is "normal"? I'm mostly enabling my services with "systemctl enable whatever.service". But since there are so many, and since there are a lot of other things to do when perparing my machines for use (e.g. put some stuff in /etc/skel, ...), I assembled a script which does these things for me.

Beside: How stable your virtual system is? I'm mostly fine with it --- up to this bug ;-)

The case that the socket /run/systemd/private does not exists indicates that systemd has been crash. It still exists, but systemd doesn't react to connections anymore, since systemd was "freezing execution" (see logfile in original bug report).

Indeed I've several virtual and real systems with systemd running and *never* catched such a crash. And I'm really stress the virtual systems in a hard way. I wish I had better information on how to reproduce the bug, but I haven't. The only reason I can guess is that the bug is more likely to appear if several systemctl calls are issued in short order.

Please attach your crash script. That's not easy. The script grew for several years, is now about 18k lines of python code and contains lots of confidential stuff. I've now distilled the systemctl command lines and put them in script.sh (attached tar file). The tar file also contains the unit files that are referenced in the script. Most of these unit files shouldn't be relevant for the bug, however.

-- 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=865188 https://bugzilla.novell.com/show_bug.cgi?id=865188#c4 Yarny Yarny changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|Yarny@public-files.de | --- Comment #4 from Yarny Yarny 2014-03-02 17:06:32 UTC --- Created an attachment (id=580643) --> (http://bugzilla.novell.com/attachment.cgi?id=580643) minimal systemd units to trigger bug The attached file contains two systemd units which, if installed, will trigger the bug by repeatedly enabling and disabling NetworkManager.service . I failed to trigger the bug without rebooting between the enable/disable steps, so the unit files also continuously reboot the system until the bug shows up. To see the bug, I performed the following steps (within VirtualBox, hosted on openSUSE 13.1, x86_64): * install openSUSE 13.1 from DVD, with minimal server selection (4 CPU cores, 48GiB HDD, 768MiB RAM, no separate /home) * install NetworkManager with zypper, thereby remove patterns-openSUSE-minimal_base-conflicts At this point it is a good idea to create a vbox snapshot to be able to restore the current state after experiments. * copy bug865188.{service,timer} to /etc/systemd/system * enable bug865188.timer and debug-shell.service * reboot (the vbox) The vbox will now enter an endless reboot cycle, and it logs its actions into the file /root/bug865188.log. To watch the progress, one can create a vbox shared folder and make this file a symlink into said folder. Then one may watch the log file on the host while the machine continuously reboots. On my vbox test machine, something between 34 and 209 cycles are needed to trigger the bug. Once the bug got triggered, the cycle ends (systemd can't initiate a reboot anymore). The debug-shell on vt10 permits to inspect the system. I also attached the output of journalctl, of dmesg, and a core file I found in the root directory after the bug occured. -- 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=865188 https://bugzilla.novell.com/show_bug.cgi?id=865188#c6 Yarny Yarny changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|Yarny@public-files.de | --- Comment #6 from Yarny Yarny 2014-03-09 17:25:59 UTC --- Several days of testing failed to reproduce the bug with systemd 210-546.1 from the link you provided. Apparently it got fixed in the newest systemd version. -- 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.