[systemd-devel] systemd+dbus: system boot stops at terminal login screen sometimes

Chen Jie chenj at lemote.com
Mon Dec 19 02:30:51 PST 2011


Hi,

2011/12/17 Michal Schmidt <mschmidt at redhat.com>:
> Chen Jie wrote:
>> Let me explain it further.
>> First syslogv() in dbus may block, while rsyslog.service is starting
>> and meanwhile the kernel socket buffer was full.
>> Attachment syslog-test.c was a program simulates the situation.
>>
>> So while rsyslog.service is starting, on the systemd side:
>> 1. [ExecStartPre] stops systemd-kmsg-syslogd.service
>> 2. It now running bus_init() to publish its API to dbus
>> 3. Step 2 timeout, because dbus-daemon didn't reply in time.
>>
>> Why dbus-daemon didn't response quickly? Because it blocked on
>> syslogv(), which was waiting for someone consumes the message(the
>> kernel socket buffer was full), but sadly the consumer -- rsyslog
>> didn't be started because systemd blocked.
>>
>> So systemd waits for dbus, and dbus waits for startup of rsyslog,
>> rsyslog waits for systemd to start it.
>
> Thanks for debugging this.
> You are right. This kind of a deadlock is possible.
>
> Does the deadlock go away if you just modify rsyslog.service so that
> instead of stopping systemd-kmsg-syslogd in ExecStartPre it would
> do it in ExecStartPost?
Yeah, it do the trick.

>
>> IMHO, We need to put functions that may block in separate threads,
>> for
>> example bus_init(), shutdown_connection(), log_meta().
>
> Oh, I'm sure this works, but I'm scared of the additional
> complexity of threads.
Agree, but IMHO, from the architectural point of view, smooth running
of systemd should not depend on quick response of outside
processes(rsyslogd, dbus).



Regards,
-- Chen Jie


More information about the systemd-devel mailing list