Bug#770644: systemd: can't start dbus if dbus is not running

[brian m. carlson]

On Sat, Mar 07, 2015 at 12:47:33AM +0100, Michael Biebl wrote:
>control: tags -1 moreinfo
>
>Am 22.11.2014 um 23:33 schrieb brian m. carlson:
>> retitle 770644 systemd: systemd is completely unusable after a fatal signal
>> # Justification: breaks the whole system, not suitable for release
>> severity 770644 serious
>> kthxbye
>>
>> On Sat, Nov 22, 2014 at 09:34:03PM +0000, brian m. carlson wrote:
>>> Package: systemd
>>> Version: 215-6
>>> Severity: important
>>>
>>> I'm trying to start strongswan:
>>>
>>>   castro ok % sudo service strongswan start
>>>   Failed to get D-Bus connection: No such file or directory
>>>
>>> Okay:
>>>
>>>   castro ok # systemctl start dbus
>>>   Failed to get D-Bus connection: No such file or directory
>>>
>>> So I start dbus by hand (à la /etc/init.d/dbus), and:
>>>
>>>   castro ok # service dbus restart
>>>   Failed to restart dbus.service: Launch helper exited with unknown return code 1
>>>   castro ok # service freeradius restart
>>>   Failed to restart freeradius.service: Launch helper exited with unknown return code 1
>>>   castro ok # sudo telinit u
>>>   Failed to execute operation: Launch helper exited with unknown return code 1
>>>
>>> Perhaps systemctl needs to learn a non-dbus way to talk to systemd.
>>> telinit should be using signals, not dbus, to signal init.
>>>
>>> systemd also does not fix itself even after receiving a SIGHUP, SIGUSR1,
>>> or SIGTERM.
>>
>> Even better is this:
>>
>> castro ok % sudo shutdown -r now
>> Failed to open initctl FIFO: No such device or address
>> Failed to talk to init daemon.
>>
>> I just noticed that the issue is that systemd called assert.  I've
>> attached an image of the console when this happened.  I don't think I
>> need to explain why using assert in /sbin/init is a bad idea.
>>
>
>Can you provide steps how this issue can be reproduced?

Unfortunately, I can't.  I provided the screenshot in hopes that it 
would be obvious to you or someone else who maintains it.  This isn't 
the first time I've seen this behavior, though; I've also seen it on my 
work laptop, but I was unable to spend a significant amount of time on 
it.

I would be fine providing you the core file (non-publicly) if you would 
like it.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150307/67d9d2e0/attachment-0002.sig>