If there are directories in the /var/run directory (eg: as used by the sudo and xemacs ports), then the line in /etc/rc that says: rm -f /var/run/* Produces an error on boot up time, which could confuse a new user. Fix: Change the above mentioned line to: rm -f /var/run/* 2>/dev/null You may also wish to add the following statement to a point after which /usr is mounted: find /var/run -type f -print | xargs rm -f How-To-Repeat: 1. Install sudo. 2. Use sudo. 3. Reboot.
> >Description: > > If there are directories in the /var/run directory (eg: as used by the > sudo and xemacs ports), then the line in /etc/rc that says: > > rm -f /var/run/* > > Produces an error on boot up time, which could confuse a new user. Same as in -STABLE. See also misc/4723. I was told that ports which create directories in /var/run are broken. However, nobody fixed the ports nor changed /etc/rc :-( (Yes, I sent a mail to the sudo port maintainer...)
On 16 May 1998, Andre Albsmeier proclaimed: > > >Description: > > > > If there are directories in the /var/run directory (eg: as used by the > > sudo and xemacs ports), then the line in /etc/rc that says: > > > > rm -f /var/run/* > > > > Produces an error on boot up time, which could confuse a new user. > > Same as in -STABLE. See also misc/4723. I was told that ports which > create directories in /var/run are broken. However, nobody fixed > the ports nor changed /etc/rc :-( (Yes, I sent a mail to the sudo > port maintainer...) To me, the idea of using a directory in /var/run doesn't seem an unreasonable thing to do. If you don't, then people just end up using /var/tmp instead for things which don't /really/ belong there. Does anybody have a defeinitive statement of what /var/run should be used for? -- allectory calyptro agal artophagous arthrocarcinoma candlerent bombastically aguavina anaesthesiant abortionist anagrammatize anthropogenetic adenia antiophthalmic brevicaudate Bothriolepis capitalizable arracach alestake calculating Amphisilidae Archencephala
State Changed From-To: open->feedback Yes, things that >SHALL< be blown away on boot. If the subdir sudo uses were removed as part of boot, would sudo make it again ? If not, could you add a etc/rc.d script which creates it and then submit a patch which zaps /var/run completely ?
In message <E0ybK5c-00007n-00.qmail@myrddin.demon.co.uk>, Dom Mitchell writes: >Poul-Henning Kamp <phk@FreeBSD.ORG> writes: > >> Synopsis: The rc script sometimes produces errors which are unnecessary. >> >> State-Changed-From-To: open->feedback >> State-Changed-By: phk >> State-Changed-When: Sun May 17 22:53:09 PDT 1998 >> State-Changed-Why: >> >> Yes, things that >SHALL< be blown away on boot. >> If the subdir sudo uses were removed as part of boot, would sudo >> make it again ? If not, could you add a etc/rc.d script which creates >> it and then submit a patch which zaps /var/run completely ? > >I'm not saying it should blow away directories under /var/run. It >should remove any files it finds though. From what I've seen, this >has to be a two stage process, removing stuff in /var/run at start and >removing stuff in subdirectories later, when /usr is mounted and find >is available. I just think that it would be much simpler to blow it all away in one operation, and expect things needed subdirs to make them again. If sudo is the only customer for subdirs at this time, I certainly think this is the way to do it. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal
In message <Pine.BSF.3.91.980519203032.411U@panda.hilink.com.au>, "Daniel O'Cal laghan" writes: > >> I just think that it would be much simpler to blow it all away in >> one operation, and expect things needed subdirs to make them again. >> >> If sudo is the only customer for subdirs at this time, I certainly >> think this is the way to do it. > >sudo, *.pid (non-root) are candidates. > >What about > >cd /var/run >rm -f * >for dir in * >do > rm -f $dir/* >done I'd rather: cd /var rm -rf run mkdir run >Also, what is the purpose of /var/preserve, please? Would that be a >better place to locate ntp.drift, rather than /etc? /var/preserve is for vi I belive. I put ntp.drift in /var/tmp -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal
On Tue, May 19, 1998 at 12:43:24PM +0200, Poul-Henning Kamp wrote: > >Also, what is the purpose of /var/preserve, please? Would that be a > >better place to locate ntp.drift, rather than /etc? > > /var/preserve is for vi I belive. From hier(7): /var/ multi-purpose log, temporary, transient, and spool files preserve/ temporary home of files preserved after an accidental death of an editor; see ex(1) > I put ntp.drift in /var/tmp My preference would be for db: db/ misc. automatically generated system-specific database files though /var/tmp is probably OK, too (it is supposed to be kept between reboots). Eivind.
On 19 May 1998, Poul-Henning Kamp proclaimed: > In message <E0ybK5c-00007n-00.qmail@myrddin.demon.co.uk>, Dom Mitchell writes > >I'm not saying it should blow away directories under /var/run. It > >should remove any files it finds though. From what I've seen, this > >has to be a two stage process, removing stuff in /var/run at start and > >removing stuff in subdirectories later, when /usr is mounted and find > >is available. > > I just think that it would be much simpler to blow it all away in > one operation, and expect things needed subdirs to make them again. I agree. That would be much cleaner. > If sudo is the only customer for subdirs at this time, I certainly > think this is the way to do it. Well, so far, the ones that I have come across are sudo and xemacs. Sudo needs it to track when a user/tty pair last executed a command. I think that xemacs is using it for lockfiles. Is there a better place for both of these to go? If so, I suggest that we fix the ports, and keep /etc/rc as is. Maybe we need a /var/ports directory, for ports to keep their own information under... -- butoxy alabamine aliquot aquocarbonic catarrhal bromacetate azoxybenzoic bimaxillary cathedralic Amaryllis abjectedness angiosclerosis blanketflower anhydric amputate brooklike baikalite autoanalysis Angelica Barsac anthropopathic bulltoad bisetose
State Changed From-To: feedback->closed phk in revision 1.145 of src/etc/rc .