On Wed, 06.07.11 16:11, Rainer Gerhards ([email protected]) wrote: > Hi all, > > I hope this is the right list. I wonder what systemd does if the > syslogd does not start when told to do so. > > Reason behind this question: in rsyslog, I try hard to record messages > even if rsyslog.conf is screwed up. For that reason, I accept > partially complete configs. And if things go really bad and I can not > get anything that "looks" working, I startup a special, hardcoded, > minimal config. All of this just in an effort to prevent log message > loss. > > Now with systemd around, I hope I can do the cleaner thing and just > err out and terminate rsyslogd. That would probably alert users much > better. It would also clean up the code and be less surprising to > users (it either works fully correct or not at all - what you usually > expect). I assume that in this situation systemd takes the log socket > over again. Am I right with that? What would be the best way to log a > message to systemd in such a situation? Via the usual syslog() > mechanism (with rsyslog being a client in this case)?
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. 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). Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
