On Wed, Jul 6, 2011 at 4:17 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Wed, 06.07.11 16:11, Rainer Gerhards (rgerha...@gmail.com) wrote: > Yes, if rsyslog dies, then systemd will notice it. As soon as there is > traffic on the /dev/log socket (which might be right-away) it will then > start the syslog-kmsg bridge again.
Will systemd make any attempt to restart syslogd if it failed? I think there is pros and cons in it: a) if syslogd failed due to config error, a restart is bad b) if syslogd failed for stability reason, a reasonable number of restarts may make sense I assume that the user can always make systemd restart syslogd, e.g. after fixing a conf problem. > So we should be reasonably safe here > that nothing is completely lost when rsyslog dies. > > From a client perspective nothing of this is visible. Clients can jus > use syslog(), and this will go to rsyslog as long as it is started, and > to kmsg before rsyslog started and after it died (regardless whether > that was abnormally or cleanly). Let's make sure we are on the same line. Sequece of events: 1. systemd starts syslogd 2. syslogd parses config, detects errors 3. syslogd logs config errors via syslog() 4. syslogd terminates Will that work? Note that at #3, syslogd has not yet terminated, so from a systemd POV it will probably look healthy. Having said that, would it make sense to somehow make syslogd flag systemd that it had a successful startup and is now ready to process messages? Rainer _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel