Your message dated Wed, 30 Sep 2015 23:39:13 +0200
with message-id <[email protected]>
and subject line Re: Bug#770644: systemd: can't start dbus if dbus is not 
running
has caused the Debian Bug report #770644,
regarding systemd: systemd is completely unusable after a fatal signal
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
770644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770644
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.

Is there a technique I can use to get my system in an operational state
without rebooting it?

The below info is not accurate because this is not being run on the
affected machine.

-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.17-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl             2.2.52-2
ii  adduser         3.113+nmu3
ii  initscripts     2.88dsf-58
ii  libacl1         2.2.52-2
ii  libaudit1       1:2.4-1
ii  libblkid1       2.25.2-3
ii  libc6           2.19-13
ii  libcap2         1:2.24-6
ii  libcap2-bin     1:2.24-6
ii  libcryptsetup4  2:1.6.6-3
ii  libgcrypt20     1.6.2-4
ii  libkmod2        18-3
ii  liblzma5        5.1.1alpha+20120614-2+b1
ii  libpam0g        1.1.8-3.1
ii  libselinux1     2.3-2
ii  libsystemd0     215-6
ii  mount           2.25.2-3
ii  sysv-rc         2.88dsf-58
ii  udev            215-6
ii  util-linux      2.25.2-3

Versions of packages systemd recommends:
ii  dbus            1.8.10-1
ii  libpam-systemd  215-6

Versions of packages systemd suggests:
pn  systemd-ui  <none>

-- Configuration Files:
/etc/systemd/system.conf changed [not included]

-- no debconf information

-- 
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

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message ---
Am 20.03.2015 um 03:45 schrieb Michael Biebl:
> Am 08.03.2015 um 15:30 schrieb brian m. carlson:
>> On Sat, Mar 07, 2015 at 12:47:33AM +0100, Michael Biebl wrote:
>>> Can you provide steps how this issue can be reproduced?
>>
>> Actually, I just discovered a set of steps on how to reproduce this:
>>
>>   Run kill -s ABRT 1
>>   Run telinit u
>>   Suspend the machine (possibly multiple times)
>>
>> When the machine unsuspends, systemd will no longer be responding to 
>> service commands.  Also, on a laptop, Network Manager will work, 
>> although the applet will indicate it's not connected.
>>
> 
> That systemd freezes when it dies is expected behaviour and the only
> real sensible thing to do. At this point, you can only reboot, to get
> back into a defined state. You'll need reboot -f here, which bypasses init.
> 
> What I was interested in, when I was asking about steps to reproduce
> this issue, is how the crash was triggered.
> I know that I can kill systemd via "kill -s ABRT 1", but that was not
> the point of my question.
> 
> I'm interested the cause for the crash.


There was no further input provided what caused the SIGABRT, thus
closing the bug report.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---

Reply via email to