Re: named pid file in /var/run/named/pid?
On Fri, Oct 05, 2001 at 11:18:18AM +0200, Bernd Walter wrote: > On Thu, Oct 04, 2001 at 03:33:35PM -0700, Crist J. Clark wrote: > > On Fri, Oct 05, 2001 at 12:03:02AM +0200, Bernd Walter wrote: > > [snip] > > > > > > It is not that big of a deal to hack this support for named into the > > > > rc scripts. It is a hassle when considering the "correct" way to > > > > handle this to make it extensible to other daemons we may wish to run > > > > in such a manner. > > > > > > The question is what is the correct way. > > > > It happens I've just been hacking around in /etc/rc where the clean-up > > of /var/run is done, and someone else mentioned mtree(8) in this > > thread (but in a different context). I think it would be easy enough > > to run mtree(8) right after /var/run is cleaned (and long after it would > > be mounted as an md(4)) to get it into good form. The problem reduces > > to maintaining the map file for this purpose. > > It's fine for the base system but what about ports? > They don't have an mtree entry but share /var/run. I didn't say maintaining the map file was going to be easy. ;) -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 03:33:35PM -0700, Crist J. Clark wrote: > On Fri, Oct 05, 2001 at 12:03:02AM +0200, Bernd Walter wrote: > [snip] > > > > It is not that big of a deal to hack this support for named into the > > > rc scripts. It is a hassle when considering the "correct" way to > > > handle this to make it extensible to other daemons we may wish to run > > > in such a manner. > > > > The question is what is the correct way. > > It happens I've just been hacking around in /etc/rc where the clean-up > of /var/run is done, and someone else mentioned mtree(8) in this > thread (but in a different context). I think it would be easy enough > to run mtree(8) right after /var/run is cleaned (and long after it would > be mounted as an md(4)) to get it into good form. The problem reduces > to maintaining the map file for this purpose. It's fine for the base system but what about ports? They don't have an mtree entry but share /var/run. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Fri, Oct 05, 2001 at 12:03:02AM +0200, Bernd Walter wrote: > On Thu, Oct 04, 2001 at 01:19:15PM -0700, Crist J. Clark wrote: [snip] > > That wouldn't work. The whole point of /var/run/named is to set the > > permissions on the directory such that a non-root user (the 'bind' > > user in FreeBSD typically) can write files in the directory. In order > > to create the named directory in /var/run, you need root privs. Give > > that to the program, and we are back where we started, no point in > > using /var/run/named, just use /var/run. > > Named is startet under root rights and drop these later. > It has to be so otherwise it's not possible to open port 53 for listen. > So there is no great magic in creating the pid file in /var/run. > If that's a problem I consider it as a bug in named. You've never 'HUPped' a named running as non-root then. It will complain about not being able to write the pid file (not that it is a fatal problem). This is the reason for /var/run/named. [snip] > > It is not that big of a deal to hack this support for named into the > > rc scripts. It is a hassle when considering the "correct" way to > > handle this to make it extensible to other daemons we may wish to run > > in such a manner. > > The question is what is the correct way. It happens I've just been hacking around in /etc/rc where the clean-up of /var/run is done, and someone else mentioned mtree(8) in this thread (but in a different context). I think it would be easy enough to run mtree(8) right after /var/run is cleaned (and long after it would be mounted as an md(4)) to get it into good form. The problem reduces to maintaining the map file for this purpose. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 01:19:15PM -0700, Crist J. Clark wrote: > On Thu, Oct 04, 2001 at 06:17:13PM +0200, Leif Neland wrote: > > On Thu, 4 Oct 2001, Jun Kuriyama wrote: > > > At Thu, 4 Oct 2001 11:21:19 + (UTC), > > > Bernd Walter wrote: > > > > I run an md based filesystem for /var/run so it is empty after startup. > > > > Does that mean that I also need to take care of creating directories in > > > > it during boot - and maintaining myself on every box. > > > > Or it it the responsibility of the programms to enshure that the > > > > directories they need are created? > > > > > > /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you > > > want to use md(4) for /var/run, you should make directory after > > > /var/run creation. > > > > Is it possible to make the md-filesystem automatically make the needed > > subdirectories, when a program wants to create > > /var/run/a/very/deeply/nested/file ? > > That wouldn't work. The whole point of /var/run/named is to set the > permissions on the directory such that a non-root user (the 'bind' > user in FreeBSD typically) can write files in the directory. In order > to create the named directory in /var/run, you need root privs. Give > that to the program, and we are back where we started, no point in > using /var/run/named, just use /var/run. Named is startet under root rights and drop these later. It has to be so otherwise it's not possible to open port 53 for listen. So there is no great magic in creating the pid file in /var/run. If that's a problem I consider it as a bug in named. > > Or would that just be too ugly, mixing device drivers with high-level file > > operations? Guess so.. > > Yeah, that too. Agreed. It's no the purpose of a filessystem to guess application needs. > It is not that big of a deal to hack this support for named into the > rc scripts. It is a hassle when considering the "correct" way to > handle this to make it extensible to other daemons we may wish to run > in such a manner. The question is what is the correct way. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 06:17:13PM +0200, Leif Neland wrote: > > > On Thu, 4 Oct 2001, Jun Kuriyama wrote: > > > At Thu, 4 Oct 2001 11:21:19 + (UTC), > > Bernd Walter wrote: > > > I run an md based filesystem for /var/run so it is empty after startup. > > > Does that mean that I also need to take care of creating directories in > > > it during boot - and maintaining myself on every box. > > > Or it it the responsibility of the programms to enshure that the > > > directories they need are created? > > > > /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you > > want to use md(4) for /var/run, you should make directory after > > /var/run creation. > > Is it possible to make the md-filesystem automatically make the needed > subdirectories, when a program wants to create > /var/run/a/very/deeply/nested/file ? That wouldn't work. The whole point of /var/run/named is to set the permissions on the directory such that a non-root user (the 'bind' user in FreeBSD typically) can write files in the directory. In order to create the named directory in /var/run, you need root privs. Give that to the program, and we are back where we started, no point in using /var/run/named, just use /var/run. > Or would that just be too ugly, mixing device drivers with high-level file > operations? Guess so.. Yeah, that too. It is not that big of a deal to hack this support for named into the rc scripts. It is a hassle when considering the "correct" way to handle this to make it extensible to other daemons we may wish to run in such a manner. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 04:09:56PM +0200, Bernd Walter wrote: > That's annoying if it becomes popular for services to use their own > subdirectory. It would be much better to get rid of pidfiles altogether. They have all sorts of nasty problems. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, 4 Oct 2001, Jun Kuriyama wrote: > At Thu, 4 Oct 2001 11:21:19 + (UTC), > Bernd Walter wrote: > > I run an md based filesystem for /var/run so it is empty after startup. > > Does that mean that I also need to take care of creating directories in > > it during boot - and maintaining myself on every box. > > Or it it the responsibility of the programms to enshure that the > > directories they need are created? > > /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you > want to use md(4) for /var/run, you should make directory after > /var/run creation. Is it possible to make the md-filesystem automatically make the needed subdirectories, when a program wants to create /var/run/a/very/deeply/nested/file ? Or would that just be too ugly, mixing device drivers with high-level file operations? Guess so.. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 10:16:25PM +0900, Jun Kuriyama wrote: > At Thu, 4 Oct 2001 11:21:19 + (UTC), > Bernd Walter wrote: > > I run an md based filesystem for /var/run so it is empty after startup. > > Does that mean that I also need to take care of creating directories in > > it during boot - and maintaining myself on every box. > > Or it it the responsibility of the programms to enshure that the > > directories they need are created? > > /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you I know. > want to use md(4) for /var/run, you should make directory after > /var/run creation. That's annoying if it becomes popular for services to use their own subdirectory. It's much better and easier if the coresponding rc file did. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: named pid file in /var/run/named/pid?
At Thu, 4 Oct 2001 11:21:19 + (UTC), Bernd Walter wrote: > I run an md based filesystem for /var/run so it is empty after startup. > Does that mean that I also need to take care of creating directories in > it during boot - and maintaining myself on every box. > Or it it the responsibility of the programms to enshure that the > directories they need are created? /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you want to use md(4) for /var/run, you should make directory after /var/run creation. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
named pid file in /var/run/named/pid?
I run an md based filesystem for /var/run so it is empty after startup. Does that mean that I also need to take care of creating directories in it during boot - and maintaining myself on every box. Or it it the responsibility of the programms to enshure that the directories they need are created? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
