sorry, looks like I forgot the CCs on my previous message. Context given in quote...
On Wed, 2009-09-02 at 13:07 +0100, Colin Watson wrote: > > The problem here is that HUP is either one of the two. So if openssh's > > init needs a restart type HUP, rsyslogd must be configured to use > > restart-type HUPs. This is no longer supported in v5 (and a bad solution > > in v3&4 for various reasons). > > We could just do '/etc/init.d/rsyslog restart', or the equivalent. It's > not perfect, but it's not that painful if you're restarting openssh too. OK, that's of course an option - but if others do the same, we may end up in a kind of "restart loop" > > > I think the wait approach would be preferrable (maybe I can do it on a > > per-socket basis with sufficient easy, need to check, but doubt it). > > I'm concerned that this would mean that log messages just vanish until > some arbitrary time after openssh starts, which will be confusing for > sysadmins who learn to expect them to be present; and that if some init > script between rsyslog and openssh blocks for ages on start, it will > cause a failure, making the whole system less robust. In general we're > trying to move the init system towards being fully event-driven, and > arbitrary delays aren't usually compatible with that. I think the socket will hold some amount of messages, so I would not expect that they totally disappear. But I may be wrong, in which case this is no real solution, agreed. Let me check if I can do something more clever with these sockets that fits into the time frame I have available... Rainer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org