Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jan 2005 18:09:45 +0100
From:      Dejan Lesjak <dejan.lesjak@ijs.si>
To:        Jose M Rodriguez <josemi@freebsd.jazztel.es>
Cc:        x11@freebsd.org
Subject:   Re: x11 /tmp preparation rc.d script
Message-ID:  <200501121809.46129.dejan.lesjak@ijs.si>
In-Reply-To: <41E2DD07.6010607@redesjm.local>
References:  <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote:
> Dejan Lesjak escribi=F3:
> >Other than that, I don't really know what would be the best way to handle
> >creation of this directories and haven't commented so far, but since I'm
> >already writing (mostly because I thought rc@ list should be CCed), here=
's
> > my opinion FWIW: the simplest seems to be a patch from Pawel Worach at
> > http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/04=
24
> >45.html The benefit of using this simple approach is that it is simple (=
of
> > course :) and furthermore it only adds two more directories to /tmp at
> > startup as oposed to adding a file in /etc/rc.d. The difference being o=
ne
> > inode. But then again, perhaps I don't see all the implications and this
> > is too simple.
>
> The only I know is that this breaks rcNG writing rules.  This is a
> little more than style.  I think that goin more modular can't hurt.

Well it is certainly an exception to how rcNG scripts are otherwise written=
,=20
but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal=
=20
of X lock file is already there as that seems the right place to do that.=20
Because of this it also seems natural (to me at least) to just add creation=
=20
of another dir there. I believe that having this in this script makes thing=
s=20
done at the right time - if one has configured to have /tmp directory clean=
ed=20
after boot, then things that should be recreated are recreated right after=
=20
that; if no other explicitly ordered cleaning up is done, these directories=
=20
(and a lock file) are still "cleaned" away and recreated with side effect o=
f=20
having the right permissions. I'm not opposed of going modular, it just see=
ms=20
that going modular for the sake of one directory is a bit of an overkill.

> >Is there a real benefit in creating another rc.d script for doing this a=
nd
> >adding a knob to turn creation of these directories off?
>
> Even more critical paths in the boot process are controlled in this
> manner. Why not?

As I said, I'm not opposed of doing it in this manner, I just don't see the=
=20
real need to create several additional scripts instead of changing two line=
s=20
in existing one that already takes care of cleaning (and preparing) /tmp=20
directory.

> >Yes of course that would only solve things on -current and -stable,
> > however
>
> This was allways the main problem of solve this 'only base'.
>
> >there is already an UPDATING entry for this and we can always add a scri=
pt
> > to be installed from a port that would take care of transition period
> > (probably as soon in dependency tree as possible, ie -libraries).
>
> There are PRs on this.  I think that latest rcNG script (with perhaps
> some tweaks to work from ports) installed from Xorg libraries will be
> the better first step.  We may make this install_script conditional when
> we have the problem solved in RELENG_5 base (test OS_VERSION) and lost
> this when RELENG_4 life cycle was expired.

I'm aware of the PRs on this, I wanted to voice my opinion on the particula=
r=20
problem of creating a directory /tmp/.ICE-unix with right permissions.
Allow me to ramble a bit more on these: If we go to "modular" way as you pu=
t=20
it, the we would have to add a script to create ICE-unix directory to, say,=
=20
=2Dlibraries ports and a script to remove lock file and X11-unix to -server=
=20
ports (more than two of them), while being careful not to let different=20
=2Dserver ports (as in server and nestserver...) step onto each others toes=
=2E Or=20
we could make additional port to only install one rc script. This is=20
certainly doable and would of course be more or less modular and could even=
=20
have knobs so one could choose if directories should be created/removed and=
=20
if lock file should be created/removed. I can't help but to think that this=
=20
would be using a bit tooo enormous hammer, that's why I still think a simpl=
e=20
solution proposed by Pawel Worach would be enough here.

Dejan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501121809.46129.dejan.lesjak>