Re: Bug#357703: udev breaks syslog
On Fri, Mar 31, 2006 at 06:28:14AM -0500, sean finney wrote: On Fri, Mar 31, 2006 at 09:47:59AM +0200, Wouter Verhelst wrote: What I'm suggesting is, actually, the reverse of a pidfile, in some way. You'd still have your /var/run/syslogd.pid; but, assuming that file contained the PID 2722 (as it currently does on my system), you'd also have a file called 2722 somewhere (say, under /var/run/pidlookups) which would contain /etc/init.d/sysklogd. With such a system, you'd be able to say restart whatever PID 2722 is. Or even to force-reload it, if that'd be enough. no offense, but this sounds more like a solution looking for a problem than the other way around. i also don't see how it is aesthetically better or cleaner than the following 4 lines of shell code: sysloginits=inetutils-syslogd metalog socklog-run sysklogd syslog-ng for s in $sysloginits; do test -x /etc/init.d/$s invoke-rc.d $s restart || true done * This doesn't scale as well. Maybe not so important if all you ever care about is syslog and udev, but there might be more cases where such a thing could be interesting and/or important. * It requires a manual update of the package every time someone adds a new syslogd to the archive. Mine does not. * It would also catch daemons that have /dev/log open, while just restarting syslogd won't cut that. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Fri, Mar 31, 2006 at 07:17:27AM +0200, Mike Hommey wrote: On Thu, Mar 30, 2006 at 10:51:03PM +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: On Thu, Mar 30, 2006 at 06:22:23PM +0100, Rich Walker wrote: Sam Morris [EMAIL PROTECTED] writes: That much is easy, but how do you turn a process ID into a script that can be invoke-rc.d'd? Make it part of the Debian spec? define a known script name (logging-daemon) that must exist in /etc/init.d/ and can be a symlink to another one. submit a small patch to each logging daemon to add/remove this link when the package is installed/removed? Sounds ugly to me. Here's another suggestion: start-stop-daemon is in a /very/ good position to know which PID belongs to which initscript. Patch it so that it writes the PIDs to some database[1] somewhere; then patch invoke-rc.d to be able to use that database. Probably best to do that through some well-defined interface, rather than having invoke-rc.d directly reading out that db, though. It already does store the pid if called with the --pidfile option. Just make it mandatory. Well, no. The --pidfile option expects the daemon to create its pid itself; it doesn't make s-s-d create it. It can't do that, either, since a proper daemon will fork() before doing anything useful, meaning, you don't have anything to check a pid of anymore. Even if it did, it isn't the solution. The pidfiles that s-s-d knows about have a something-pid mapping. There is no link to the exact initscript that needs to be called (the initscript is supposed to know where its pidfile is), so they're not very useful. And if you fix that, you're still faced with the problem that to look up the pidfile that belogns to a given PID, you need to open() all those files in sequence until you find the right one, which isn't very efficient. What I'm suggesting is, actually, the reverse of a pidfile, in some way. You'd still have your /var/run/syslogd.pid; but, assuming that file contained the PID 2722 (as it currently does on my system), you'd also have a file called 2722 somewhere (say, under /var/run/pidlookups) which would contain /etc/init.d/sysklogd. With such a system, you'd be able to say restart whatever PID 2722 is. Or even to force-reload it, if that'd be enough. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Fri, Mar 31, 2006 at 09:47:59AM +0200, Wouter Verhelst wrote: What I'm suggesting is, actually, the reverse of a pidfile, in some way. You'd still have your /var/run/syslogd.pid; but, assuming that file contained the PID 2722 (as it currently does on my system), you'd also have a file called 2722 somewhere (say, under /var/run/pidlookups) which would contain /etc/init.d/sysklogd. With such a system, you'd be able to say restart whatever PID 2722 is. Or even to force-reload it, if that'd be enough. no offense, but this sounds more like a solution looking for a problem than the other way around. i also don't see how it is aesthetically better or cleaner than the following 4 lines of shell code: sysloginits=inetutils-syslogd metalog socklog-run sysklogd syslog-ng for s in $sysloginits; do test -x /etc/init.d/$s invoke-rc.d $s restart || true done (granted, the init scripts are actually named differently than the package names, but you should see my point) sean signature.asc Description: Digital signature
Re: Bug#357703: udev breaks syslog
sean finney [EMAIL PROTECTED] wrote: sysloginits=inetutils-syslogd metalog socklog-run sysklogd syslog-ng for s in $sysloginits; do test -x /etc/init.d/$s invoke-rc.d $s restart || true done Well, that would try to start each installed service, even if that is not intended by the local admin (no start links in /etc/rc?.d/). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#357703: udev breaks syslog
This one time, at band camp, Frank Küster said: sean finney [EMAIL PROTECTED] wrote: sysloginits=inetutils-syslogd metalog socklog-run sysklogd syslog-ng for s in $sysloginits; do test -x /etc/init.d/$s invoke-rc.d $s restart || true done Well, that would try to start each installed service, even if that is not intended by the local admin (no start links in /etc/rc?.d/). Doesn't invoke-rc.d already have that logic built in? I sort of thought that was the point of it. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#357703: udev breaks syslog
pe, 2006-03-31 kello 13:07 +0100, Stephen Gran kirjoitti: This one time, at band camp, Frank Küster said: sean finney [EMAIL PROTECTED] wrote: sysloginits=inetutils-syslogd metalog socklog-run sysklogd syslog-ng for s in $sysloginits; do test -x /etc/init.d/$s invoke-rc.d $s restart || true done Well, that would try to start each installed service, even if that is not intended by the local admin (no start links in /etc/rc?.d/). Doesn't invoke-rc.d already have that logic built in? I sort of thought that was the point of it. Yep, from the manual page: invoke-rc.d is a generic interface to execute System V style init script /etc/init.d/name actions, obeying runlevel constraints as well as any local policies set by the system administrator. The part about local policies means running policy-rc.d if it exists (which is very handy, for example for piuparts, which uses it to try to prevent all services from being started). -- I'm a Luddite with neophilia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Wed, 29 Mar 2006, Marc Haber wrote: On Tue, 28 Mar 2006 18:15:27 +0200, [EMAIL PROTECTED] (Marco d'Itri) wrote: On Mar 28, Gabor Gombas [EMAIL PROTECTED] wrote: How about restarting syslog (or it's equivalent) after relocating the old /dev? glibc already has infrastructure for restarting services on upgrade, maybe udev can borrow that. Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? One more sign that we need out syslog daemon packages to cooperate better. Which is kind of hard if not impossible considering the current state of sysklogd packaging, which is unfortunately still the default. A common interface for adding additional locations of logging sockets would also be nice. So that packages could tell the local syslogd to please create a socket in /chroots/bind/dev/log and then chroot by default. Cheers, Peter PS: and I want a pony too, please -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
Peter Palfrader [EMAIL PROTECTED] writes: A common interface for adding additional locations of logging sockets would also be nice. So that packages could tell the local syslogd to please create a socket in /chroots/bind/dev/log and then chroot by default. In this case, one way of doing this for chroots would be for syslog packages to provide a file e.g. /etc/schroot/setup.d/50syslog which would create the socket on the fly when the chroot is used. This does require using schroot to access chroots, however. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpPs4heq1gGG.pgp Description: PGP signature
Re: Bug#357703: udev breaks syslog
On Tuesday 28 March 2006 18:15, Marco d'Itri wrote: On Mar 28, Gabor Gombas [EMAIL PROTECTED] wrote: How about restarting syslog (or it's equivalent) after relocating the old /dev? glibc already has infrastructure for restarting services on upgrade, maybe udev can borrow that. Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? Look in /proc and find out which process has the log socket open? If that process belongs to one of the packaged syslog implementations (there aren't that many!) restart it. (Taking advantage of the fact that IIRC processes printing log messages open and close the socket for every messages, so looking a few times until abs(the intersection of all processes on that socket) == 1 should be safe. -- vbi -- Protect your privacy - encrypt your email: http://fortytwo.ch/gpg/intro pgp6EGgdiVySL.pgp Description: PGP signature
Re: Bug#357703: udev breaks syslog
On 3/30/06, Adrian von Bidder [EMAIL PROTECTED] wrote: On Tuesday 28 March 2006 18:15, Marco d'Itri wrote: On Mar 28, Gabor Gombas [EMAIL PROTECTED] wrote: How about restarting syslog (or it's equivalent) after relocating the old /dev? glibc already has infrastructure for restarting services on upgrade, maybe udev can borrow that. Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? Look in /proc and find out which process has the log socket open? If that Can you depend on /proc being available?
Re: Bug#357703: udev breaks syslog
On Tuesday 28 March 2006 18:15, Marco d'Itri wrote: On Mar 28, Gabor Gombas [EMAIL PROTECTED] wrote: How about restarting syslog (or it's equivalent) after relocating the old /dev? glibc already has infrastructure for restarting services on upgrade, maybe udev can borrow that. Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? Look in /proc and find out which process has the log socket open? If that process belongs to one of the packaged syslog implementations (there aren't that many!) restart it. That much is easy, but how do you turn a process ID into a script that can be invoke-rc.d'd? Well, I suppose one could hard code in a list of packaged syslog daemons and the names of their init scripts, but that's pretty nasty. IMO this is just foolishness caused by the hacks necessary to start udev immediatly after the package has been installed, rather than after the system is rebooted. -- vbi -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Thu, 2006-03-30 at 18:22 +0200, Adrian von Bidder wrote: (Taking advantage of the fact that IIRC processes printing log messages open and close the socket for every messages, so looking a few times until abs(the intersection of all processes on that socket) == 1 should be safe. It's not that obvious. There are function (at least in C) to open a socket to syslog (openlog). If a program use this, then it will keep the connection open till the end of the program. (Or till the next closelog call. :) ) In my destop system there are about 6 stable connection into /dev/log. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
Sam Morris [EMAIL PROTECTED] writes: That much is easy, but how do you turn a process ID into a script that can be invoke-rc.d'd? Make it part of the Debian spec? define a known script name (logging-daemon) that must exist in /etc/init.d/ and can be a symlink to another one. submit a small patch to each logging daemon to add/remove this link when the package is installed/removed? -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Mar 30, Peter Palfrader [EMAIL PROTECTED] wrote: A common interface for adding additional locations of logging sockets would also be nice. So that packages could tell the local syslogd to please create a socket in /chroots/bind/dev/log and then chroot by default. *Many* years ago I opened a sysklogd bug with a patch to do this, but I recently closed it because it was ignored. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#357703: udev breaks syslog
On Thu, Mar 30, 2006 at 06:22:23PM +0100, Rich Walker wrote: Sam Morris [EMAIL PROTECTED] writes: That much is easy, but how do you turn a process ID into a script that can be invoke-rc.d'd? Make it part of the Debian spec? define a known script name (logging-daemon) that must exist in /etc/init.d/ and can be a symlink to another one. submit a small patch to each logging daemon to add/remove this link when the package is installed/removed? Sounds ugly to me. Here's another suggestion: start-stop-daemon is in a /very/ good position to know which PID belongs to which initscript. Patch it so that it writes the PIDs to some database[1] somewhere; then patch invoke-rc.d to be able to use that database. Probably best to do that through some well-defined interface, rather than having invoke-rc.d directly reading out that db, though. [1] database, as in, some way to store PIDs and which initscript they belong to, not necessarily as in libdb, and absolutely not as in SQL-engine with data files. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Thu, Mar 30, 2006 at 10:51:03PM +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: On Thu, Mar 30, 2006 at 06:22:23PM +0100, Rich Walker wrote: Sam Morris [EMAIL PROTECTED] writes: That much is easy, but how do you turn a process ID into a script that can be invoke-rc.d'd? Make it part of the Debian spec? define a known script name (logging-daemon) that must exist in /etc/init.d/ and can be a symlink to another one. submit a small patch to each logging daemon to add/remove this link when the package is installed/removed? Sounds ugly to me. Here's another suggestion: start-stop-daemon is in a /very/ good position to know which PID belongs to which initscript. Patch it so that it writes the PIDs to some database[1] somewhere; then patch invoke-rc.d to be able to use that database. Probably best to do that through some well-defined interface, rather than having invoke-rc.d directly reading out that db, though. It already does store the pid if called with the --pidfile option. Just make it mandatory. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Tue, 28 Mar 2006 18:15:27 +0200, [EMAIL PROTECTED] (Marco d'Itri) wrote: On Mar 28, Gabor Gombas [EMAIL PROTECTED] wrote: How about restarting syslog (or it's equivalent) after relocating the old /dev? glibc already has infrastructure for restarting services on upgrade, maybe udev can borrow that. Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? One more sign that we need out syslog daemon packages to cooperate better. Which is kind of hard if not impossible considering the current state of sysklogd packaging, which is unfortunately still the default. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Bug#357703: udev breaks syslog
Does anybody have an opinion about this? When udev is installed for the first time on a running system the current /dev/log socket ends up in /dev/.static/ (which is not world-readable) until the next reboot. On Mar 19, Marco d'Itri [EMAIL PROTECTED] wrote: On Mar 19, Richard Kettlewell [EMAIL PROTECTED] wrote: $ ls -l /dev/log lrwxrwxrwx 1 root root 20 Mar 4 17:03 /dev/log - /dev/.static/dev/log This only happen between the first time you install it and you reboot the system. I am open to more solutions. Should I bind-mount the socket? -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#357703: udev breaks syslog
On Tue, Mar 28, 2006 at 12:57:24PM +0200, Marco d'Itri wrote: Does anybody have an opinion about this? When udev is installed for the first time on a running system the current /dev/log socket ends up in /dev/.static/ (which is not world-readable) until the next reboot. How about restarting syslog (or it's equivalent) after relocating the old /dev? glibc already has infrastructure for restarting services on upgrade, maybe udev can borrow that. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Bug#357703: udev breaks syslog
On Mar 28, Gabor Gombas [EMAIL PROTECTED] wrote: How about restarting syslog (or it's equivalent) after relocating the old /dev? glibc already has infrastructure for restarting services on upgrade, maybe udev can borrow that. Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#357703: udev breaks syslog
On Tue, Mar 28, 2006 at 06:15:27PM +0200, Marco d'Itri wrote: Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? are there really that many syslog daemons (my count is 5)? why not make a list, fire off invoke-rc.d on each of them during upgrade, and ignore the return codes? if you really cared i suppose you couldtest before calling invoke-rc.d too, but the point is i don't think it's a great deal of work to do so. sean signature.asc Description: Digital signature
Re: Bug#357703: udev breaks syslog
On 3/28/06, sean finney [EMAIL PROTECTED] wrote: On Tue, Mar 28, 2006 at 06:15:27PM +0200, Marco d'Itri wrote: Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? are there really that many syslog daemons (my count is 5)? why not make a list, fire off invoke-rc.d on each of them during upgrade, and ignore the return codes? if you really cared i suppose you couldtest before calling invoke-rc.d too, but the point is i don't think it's a great deal of work to do so. That doesn't sound like a clean solution. :) I doubt udev/syslog are the only packages that encounter this situation.
Re: Bug#357703: udev breaks syslog
Olaf van der Spek [EMAIL PROTECTED] writes: On 3/28/06, sean finney [EMAIL PROTECTED] wrote: On Tue, Mar 28, 2006 at 06:15:27PM +0200, Marco d'Itri wrote: Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? are there really that many syslog daemons (my count is 5)? why not make a list, fire off invoke-rc.d on each of them during upgrade, and ignore the return codes? if you really cared i suppose you couldtest before calling invoke-rc.d too, but the point is i don't think it's a great deal of work to do so. That doesn't sound like a clean solution. :) I doubt udev/syslog are the only packages that encounter this situation. There are a number of situations where one of a selection of packages can reasonably be installed. mail transport agent imap daemon dns server proxy server logging daemon Presumably, there is a standard way to handle the case of needing to restart a 1-of-N service handler? cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Tue, Mar 28, 2006 at 06:15:27PM +0200, Marco d'Itri wrote: Harder than it looks. There are multiple syslog daemons, how can the package know which one is installed and needs to be restarted? glibc already checks for more than 40 packages and restarts only those that are installed. I doubt there are that many packages that needs a restart on udev install/upgrade. It's true that it is not a clean solution that udev needs to keep track of the packages that should be restarted, but this method works now while a more sophisticated method needs someone to design implement it. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
