[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LP for rc (udpated)
On Sun, Jul 01, 2001 at 08:37:49PM -0700, Dave Taira wrote:
> On Sun, 1 Jul 2001, [iso-8859-1] Gerardo Santana Gómez Garrido wrote:
>
> One caveat. I'm looking at a machine running 2.9-stable, upgraded
> from 2.8-stable.
>
> > b) I was surprised when I found an rc file that sometimes it checks for
> > existing executable files, but sometimes not;
>
> I'm can't say about the few times it checks daemons via -x.
I don't know either. But something is wrong in rc.
It doesn't test for portmap, syslogd, but it does test for
ldconfig and kbd.
> But it occurs to me that, if a given daemon doesn't exist, then
> the attempt to start it up will generated an error, indicating that
> the daemon doesn't exist or isn't executable. If that's the case for
> something you expect to be there and start up, you want it reported.
> Adding the test, IMHO, doesn't gain you anything.
Aha. It's reasonable.
But then we could think about avoiding test for config files, and special
files too, because we may want it reported "if that's the case for something
you expect to be there and start up"
Because this doesn't make sense now, it seems reasonable to have some "if-else"s
over there, warning about not finding required preconditions.
We could then think about writing a single wrapper for all commands, so we get
a common interface for running a command/script, and just set preconditions
as paramaters evaluated by this wrapper.
Too complex? Yes. But we'll have now full testing and warning.
Or, we could just forget the testing and let the error messages show in
the console when something gets wrong.
What's the best approach...
I mean, rc should follow rules, whatever they are.
> I don't know why there's a -f test for ldconfig.
It was awesome, yes. And a -f for /sbin/kbd too.
>
> > sometimes it checks for readable files, and sometimes just for existance;
>
> `grep -- -r /etc/rc` gets me three `rm -rf`s and one `pax -rw`.
> Do do you have an example that I'm missing? That aside, checking for
> read/write access doesn't mean much when you're running as root.
Sorry. I made a mistake. Forget the "readable". I mean -e vs. -f
It sometimes uses -e, and sometimes -f.
Anyways, -r should be used for correctness.
We could assume the commands/daemons/scripts will always be running as root.
Assupmtions and generalizing are both source of many (all?) mistakes.
>
> > sometimes uses full paths for commands, and sometimes not.
>
> PATH gets defined:
> PATH=/sbin:/bin:/usr/sbin:/usr/bin
> export PATH
I wonder why some /usr/bin/command and /usr/sbin/command appear then in the
current rc file. If they're not needed, they shouldn't be there, right?
I think rc should be uniformed.
>
> Checking for size greater than zero (-s rather than -f) also, I think,
> doesn't gain anything. A daemon should either read the empty config
> file and do nothing, or complain about a 0-byte config.
Then again, I think rc should be uniformed.
For correctness, -s should be tested in the sysctl case for example, or the
raid devices. If there're no devices to configure, why does rc need to run
raidctl (the same for sysctl).
Otherwise let's remove the -s test from nfs, sendmail, and others too.
--
ISC. Gerardo Santana Gómez Garrido
OpenBSD México http://www.openbsd.org.mx/~santana
4291424