Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Wed, May 29, 2002 at 05:03:02AM +0400, .@babolo.ru wrote: I doubt that goes to ports ever. Make Problem Report. ports/38674 -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
Just fwiw (probably nothing), I'd like to express a strong yes please vote for a move in this direction. I currently use djb's daemontools to manage qmail and dnsserver+tinydns, and am pretty sure that I'm going to migrate the rest of my /usr/local/etc/rc.d services under there too, now that I have a reasonable understanding of how it works. None of these run as root, so .pid files wouldn't work well anyway. About the only thing that daemontools doesn't offer in this regard is the sort of dependency-directed start order being discussed for the new /etc/rc.d (and present in NetBSD). I'm not sure what to make of that. I suspect that djb just expects services that depend on other services to wait around until the other service is running (perhaps by exiting so that the service manager can start it again five seconds later). I'm not sure that I can see a problem with that, frankly: not being able to cope with unresponsiveness of some other service implies fragility in the face of restarting or failure of that other service. Maybe there are races or deadlocks that way? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Tue, May 28, 2002 at 03:42:31AM +0400, .@babolo.ru wrote: Begin with port. Please find attached a port skeleton for mktool 0.0.7. Perhaps we can suggest a more descriptive name to the author (cc'ed)? Feedback welcome. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; mktool.shar Description: Unix shell archive
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
Jos Backus writes: On Tue, May 28, 2002 at 03:42:31AM +0400, .@babolo.ru wrote: Begin with port. Please find attached a port skeleton for mktool 0.0.7. Perhaps we can suggest a more descriptive name to the author (cc'ed)? Feedback welcome. I doubt that goes to ports ever. Make Problem Report. man send-pr -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Wed, May 29, 2002 at 05:03:02AM +0400, .@babolo.ru wrote: I doubt that goes to ports ever. Make Problem Report. man send-pr Allright, allright :-) But let me remind you that I don't want this to be a port, I want it to become part of the base OS. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
[Redirecting to the hackers list -- please respect the reply-to header] Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
As this thread once more suggests, the whole concept of pidfiles is broken. The proper way is to use a service control manager which keeps track of processes, allowing them to be stopped/restarted etc. through a single API. (I am not going to mention AIX's System Resource Controller again because some people on this list don't seem to like AIX.) Last time the discussion about daemontools seemed to end in it being a good idea but djb's license being unsuitable, iIrc. So on the 22nd I sent an e-mail to -hackers saying that I have found a BSD-licensed service control manager suitable for import into the base OS, in the hope of restarting this discussion. init(8) doesn't cut it for various reasons: single config file, runs as root, critical to system startup, etc. But it appears I am in a minority because so far I have only received one private response. Mnsho, of course. Jos On Mon, May 27, 2002 at 12:24:56PM -0600, Lyndon Nerenberg wrote: [Redirecting to the hackers list -- please respect the reply-to header] Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On 27 May 2002, at 12:24, Lyndon Nerenberg boldly uttered: [Redirecting to the hackers list -- please respect the reply-to header] Sigh, well I guess I have another reason to join that list, what the heck.. Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. --lyndon Funny thing about that, I actually created a /var/run/named directory for just the purpose of running named in a 'sandbox', chowned the directory bind:bind, and because I forgot to set the pid file path in named.conf, I see that it seems to write named.pid (owned by bind:bind) into /var/run without a problem. I know some processes demote themselves after they initialize, maybe this is what the named daemon does. But you wouldn't know it, given the ownership of the pid file. (I'm sure this makes sense to people who know about this stuff, it still confuses me) Maybe the daemon creates the file as root than chown's it? -- Philip J. Koenig [EMAIL PROTECTED] Electric Kahuna Systems -- Computers Communications for the New Millenium To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
pjklist Funny thing about that, I actually created a /var/run/named directory pjklist for just the purpose of running named in a 'sandbox', chowned the pjklist directory bind:bind, and because I forgot to set the pid file path in pjklist named.conf, I see that it seems to write named.pid (owned by pjklist bind:bind) into /var/run without a problem. For named, the initial creation isn't the problem, it's the reloads and restarts: # ndc reload Reload initiated. # tail -2 /var/log/messages May 27 12:36:35 horsey named[142]: couldn't create pid file '/var/run/named.pid' May 27 12:36:35 horsey named[142]: Ready to answer queries. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On 27 May 2002, at 12:38, Gregory Neil Shapiro boldly uttered: pjklist Funny thing about that, I actually created a /var/run/named directory pjklist for just the purpose of running named in a 'sandbox', chowned the pjklist directory bind:bind, and because I forgot to set the pid file path in pjklist named.conf, I see that it seems to write named.pid (owned by pjklist bind:bind) into /var/run without a problem. For named, the initial creation isn't the problem, it's the reloads and restarts: # ndc reload Reload initiated. # tail -2 /var/log/messages May 27 12:36:35 horsey named[142]: couldn't create pid file '/var/run/named.pid' May 27 12:36:35 horsey named[142]: Ready to answer queries. Good point, I think I've seen that before. SO I suppose it's safe to say there is a different method of startup, IE named apparently creates the pid file as root, then chowns it afterwards and demotes itself, whereas sendmail doesn't bother. (not that it matters, as you mention, since named's handicap is just delayed) I have to say that with Bind-9, the fact that it starts as one uid and ends up as another is a hassle, because it makes logging more complicated than it should be. (starting as root then demoting, startup messages can only be logged in syslog, when I prefer logging everything to dedicated named logfiles) -- Philip J. Koenig [EMAIL PROTECTED] Electric Kahuna Systems -- Computers Communications for the New Millenium To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
Jos Backus writes: As this thread once more suggests, the whole concept of pidfiles is broken. The proper way is to use a service control manager which keeps track of processes, allowing them to be stopped/restarted etc. through a single API. (I I understand, but there no control manager now, and I suggest some tuning of rights --- etc/mtree/BSD.var.dist Mon Jan 14 14:23:15 2002 +++ etc/mtree/BSD.var.dist Sat Mar 9 20:32:38 2002 @@ -53,7 +53,7 @@ .. preserve .. -run +run gname=daemon mode=1775 ppp gname=network mode=0770 .. .. and every daemon in group 'daemon' while no better method am not going to mention AIX's System Resource Controller again because some people on this list don't seem to like AIX.) Last time the discussion about daemontools seemed to end in it being a good idea but djb's license being unsuitable, iIrc. So on the 22nd I sent an e-mail to -hackers saying that I have found a BSD-licensed service control manager suitable for import into the base OS, in the hope of restarting this discussion. init(8) doesn't cut it for various reasons: single config file, runs as root, critical to system startup, etc. I have a lot of troubles with djb's tools in jail environment: they are unreliable. Are you sure that http://www.io.com/~manoj/file/mktool-0.0.7.tar.gz (are you mean this one?) is better? I do not find docs or mans and am not sure that it is worth-while to dig in thist code instead of simple shell scripts (as in ports/38593 - that is my way to service control manager) But it appears I am in a minority because so far I have only received one private response. Mnsho, of course. Jos On Mon, May 27, 2002 at 12:24:56PM -0600, Lyndon Nerenberg wrote: [Redirecting to the hackers list -- please respect the reply-to header] Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Tue, May 28, 2002 at 01:36:00AM +0400, .@babolo.ru wrote: I have a lot of troubles with djb's tools in jail environment: they are unreliable. Huh? What is the problem? While the license causes plenty of problems I have yet to see the programs themselves cause any. Now they may not be a natural fit to what you are trying to do in this case but that doesn't invalidate the idea of a service control manager in general - only perhaps the daemontools implementation for your particular application. Are you sure that http://www.io.com/~manoj/file/mktool-0.0.7.tar.gz (are you mean this one?) is better? It's hackable, which compared to daemontools is a big plus. And the author has said he is willing to add some more improvements and documentation. I do not find docs or mans and am not sure that it is worth-while to dig in thist code instead of simple shell scripts (as in ports/38593 - that is my way to service control manager) Re: docs, see above. If there's sufficient interest I can prod the author or write some myself. The problem with all these homegrown solutions is that they are not portable and lack the necessary features to be of general use, among others. I think first there needs to be consensus that having some sort of service control manager in the base OS is a good idea. Then we can look into possible candidates. Given the long tradition that pidfiles have in UNIX this is probably an uphill battle, even though I think there are plenty of reasons to consider them the result of poor engineering. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
In message [EMAIL PROTECTED], Lyndon Nerenberg writes : [Redirecting to the hackers list -- please respect the reply-to header] Claus == Claus Assmann [EMAIL PROTECTED] writes: Claus On Mon, May 27, 2002, Philip J. Koenig wrote: Any particular reason why the sendmail with 4.6-RC is writing sm- client.pid into /var/spool/clientmqueue instead of /var/run? Claus Permissions. This points out a short-fall in the /var/run scheme: it can only be used by processes running with an euid of 0 at the time they create the file. If we have a /var/run/sendmail directory owned by the smmsp user then sendmail can create its pid files there. Likewise for bind. The purgedir function in /etc/rc (used to clean /var/run) will preserve the existing directory structure under /var/run, so the sub-directory tree will survive reboots. Maybe not for named because you're better off using the -t option. -- Cheers, Phone: 250-387-8437 Cy SchubertFax: 250-387-5766 Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED] Open Systems Group, CITS Ministry of Management Services Province of BC FreeBSD UNIX: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
Jos Backus writes: On Tue, May 28, 2002 at 01:36:00AM +0400, .@babolo.ru wrote: I have a lot of troubles with djb's tools in jail environment: they are unreliable. Huh? What is the problem? While the license causes plenty of problems I have yet to see the programs themselves cause any. Now they may not be a natural fit to what you are trying to do in this case but that doesn't invalidate the idea of a service control manager in general - only perhaps the daemontools implementation for your particular application. There are usual retrieval errors in jail+nullfs on startup I never see without jail+nullfs. May be it is the reason for daemontools not to work reliable when nonexpected errors occur - but I am not shure because a lack of time. Are you sure that http://www.io.com/~manoj/file/mktool-0.0.7.tar.gz (are you mean this one?) is better? It's hackable, which compared to daemontools is a big plus. And the author has said he is willing to add some more improvements and documentation. And it is simple. And not terrible disturb usual agreements. Good candidate for ports? as first step to your aim. I do not find docs or mans and am not sure that it is worth-while to dig in thist code instead of simple shell scripts (as in ports/38593 - that is my way to service control manager) Re: docs, see above. If there's sufficient interest I can prod the author or write some myself. Begin with port. I am interested in particular. For my hundreds jailed services The problem with all these homegrown solutions is that they are not portable jails not portable now. But it is most reliable way now. and lack the necessary features to be of general use, among others. Yes. I think first there needs to be consensus that having some sort of service control manager in the base OS is a good idea. Then we can look into possible candidates. Given the long tradition that pidfiles have in UNIX this is probably an uphill battle, even though I think there are plenty of reasons to consider them the result of poor engineering. The way: - make a port of service control manager(s) which writes down own pid as usual but handles controled processes himself - give a control step by step (service by service) - may be at FreeBSD 6..8 time it will be accepted in base -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Tue, May 28, 2002 at 03:42:31AM +0400, .@babolo.ru wrote: There are usual retrieval errors in jail+nullfs on startup I never see without jail+nullfs. May be it is the reason for daemontools not to work reliable when nonexpected errors occur - but I am not shure because a lack of time. Possibly, yes. And it is simple. And not terrible disturb usual agreements. Good candidate for ports? as first step to your aim. I would like to see this integrated into the base OS (a la inetd) to manage the daemons that are already part of the base OS and are currently not being managed. First, people have to agree that having some kind of generic service control manager is a good idea. After all, inetd was written so people would not have to duplicate its functionality every time. inetd could be run under this manager btw. If people think this is a bad idea (and consequently think that pidfiles are the right solution for this type of problem instead of fork()/wait()) I suppose I (or somebody else) could create a port but my main goal would have been lost at that point. I would really like some more discussion on the pros and cons of the basic idea. Begin with port. I am interested in particular. For my hundreds jailed services See above... The problem with all these homegrown solutions is that they are not portable jails not portable now. But it is most reliable way now. Yes, some OS constructs such as jails are non-portable but service monitoring should not be one of them. The SysV rc.d mechanism, while standardized, doesn't provide for any kind of monitoring facility. This software fills that gap, and it would be nice to see the *BSDs at least to incorporate this functionality. The way: - make a port of service control manager(s) which writes down own pid as usual but handles controled processes himself I will look into creating a port since you insist :-) - give a control step by step (service by service) I'm not sure what you mean by this? - may be at FreeBSD 6..8 time it will be accepted in base I will have given up long before if it looks like it is going to take that long to get such basic functionality into FreeBSD. Thanks for your feedback. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: non-root /var/run files (was Re: Sendmail, smmsp, and pid file)
On Mon, 2002-05-27 at 13:38, Gregory Neil Shapiro wrote: pjklist Funny thing about that, I actually created a /var/run/named directory pjklist for just the purpose of running named in a 'sandbox', chowned the pjklist directory bind:bind, and because I forgot to set the pid file path in pjklist named.conf, I see that it seems to write named.pid (owned by pjklist bind:bind) into /var/run without a problem. For named, the initial creation isn't the problem, it's the reloads and restarts: # ndc reload Reload initiated. # tail -2 /var/log/messages May 27 12:36:35 horsey named[142]: couldn't create pid file '/var/run/named.pid' May 27 12:36:35 horsey named[142]: Ready to answer queries. named(8) starts up as root, but demotes itself and chroots to the sandbox immediately after reading the command line. I assume it creates the pid file as soon as it starts up, before it processes its arguments. Using ndc isn't a problem if you use the -c option to point it to the correct socket. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
