Date: Sun, 24 Sep 1995 13:39:10 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jmb@kryten.Atinc.COM (Jonathan M. Bresler) Cc: peter@taronga.com, hackers@FreeBSD.ORG Subject: Re: ports startup scripts Message-ID: <199509242039.NAA03797@phaeton.artisoft.com> In-Reply-To: <Pine.3.89.9509232038.B7901-0100000@kryten.atinc.com> from "Jonathan M. Bresler" at Sep 23, 95 08:57:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> with the K* and S* files in different directories, one for each > run level, ascertaining the differences is needlessly harder. > > consider instead a file that lists which scripts to run for each > 'run level or the term of the day we are using' and the order of > execution. now if both level A and level B need script Sfoo, there is > only one Sfoo. no symlinks required. no hard links required. it is > immediately obvious what is differnct and what is the same among the run > levels. > > same name == same script == same actions. > > no grep'ping. no diff'ing. no uncertainty. Uncertainty on package install/deinstall. Consider: A package which requires a daemon to be run needs to add a startup and a shutdown script to the list of scripts to be executed. It may also need to add a cron job to rotate the damons logs. A single file containing this information requires additional locking, etc. to make it work properly (consider: one package being installed in one xterm and another being installed in another). The point of using seperate files is that the directory entry/deletion mechanism is arbitrated automatically, in the kernel, without the use of user level locks. A seperate file does not require a grep/sed of the single monolithic data file to add/delete. Ordering guarantees within a single run level/state are hard to provide with the single monolithic file model. Finally, what if I don't want to delete the package, I just want to disable it? How to I prevent the package daemon's and cron jobs from running without losing the information needed to reeenable them later without needing to fully reinstall them? Typically, I'd put the "cron" jobs as at commands in the startup script, though this begs the question of providing configurability under administrative control (for instance, what if I want to specify a higher or lower frequency of log rotation?). Cron actually faces the same issues as init. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509242039.NAA03797>