Hi, 2011/12/17 Michal Schmidt <[email protected]>: > 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
