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? > 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. Michal _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
