dave@westmark.UUCP (Dave Levenson) (04/04/89)
I need to alter the list of daemons running under SysV/386 Rel 3.2,
but I believe the question is applicable to most UNIX versions:
When is it ever safe to edit /etc/inittab when UNIX is running?
The init(1) program reads this file whenever it is told to by
telinit or init Q. It also reads this file whenever one of its
children dies.
If I'm editing the file, and have decided to re-write it just as
init decides to re-read it, there is an interval where the file does
not exist. (The editor has unlinked the old file, and hasn't yet
linked the new file to the name. -- Or worse, the editor has opened
the file for writing, and truncated it, and hasn't yet finished
writing the new contents.) Init tries to read the inittab file,
finds that it doesn't exist, and kills off its remaining children.
It logs me off (and any other users who happen to be there. It
leaves the machine in single-user mode with a root shell on the
console.
Is there a way to hold off init long enough to re-write the inittab
after its contents have been changed? Is there an atomic way of
relinking the file? Can I lock the file?
If I cannot predict when some random daemon or logged-in user might
exit and wakeup init, how can I tell when it's safe to edit inittab?
--
Dave Levenson /-----------------------------\
Westmark, Inc. | If you can't give me your |
Warren, NJ USA | Phone number, don't call! |
{rutgers | att}!westmark!dave \-----------------------------/mrb1@homxc.ATT.COM (M.BAKER) (04/06/89)
In article <1166@westmark.UUCP>, dave@westmark.UUCP (Dave Levenson) writes: > .................... > When is it ever safe to edit /etc/inittab when UNIX is running? > The init(1) program reads this file whenever it is told to by > telinit or init Q. It also reads this file whenever one of its > children dies. > ................... I wondered about this too, but used to just go and edit /etc/inittab on a "live" system anyhow (UNIX System V/386/3.2 on a 6386(E)). No- thing bad seemed to happen [perhaps they have some kind of file locking mechanism during the change], but.... After the kernel was rebuilt (following a tunable parameter change, installing a new/revised driver, etc.) things just didn't seem right. /etc/getty's weren't there anymore, and so on. Then I realized that /etc/inittab was being rebuilt each time by appending /etc/conf/cf.d/init.base with any files in /etc/conf/init.d directory. IDMKINIT(1M) gives full particulars of this. It also describes its use as a user-level command to test new /etc/inittab versions before a real rebuild, along with its use in shell scripts which need to change /etc/inittab but do not reconfigure the kernel. I would recommend making my changes in init.base, and the append files in init.d directory, and then running IDMKINIT to produce an intermediate version of the new /etc/inittab in /etc/conf/cf.d directory. Then you can copy it over the real /etc/inittab, and init q. This will make sure /etc/inittab is what you want after a kernel rebuild, too. Of course, stash the old versions of all modified files away someplace safe, just in case :-) Hope this helps, or at least is not "bad" advice. M. Baker homxc!mrb1
rwhite@nusdhub.UUCP (Robert C. White Jr.) (04/07/89)
in article <1166@westmark.UUCP>, dave@westmark.UUCP (Dave Levenson) says: > > I need to alter the list of daemons running under SysV/386 Rel 3.2, > but I believe the question is applicable to most UNIX versions: > > When is it ever safe to edit /etc/inittab when UNIX is running? > The init(1) program reads this file whenever it is told to by > telinit or init Q. It also reads this file whenever one of its > children dies. According to my manual init does not re-read inittab when a process dies. Init builds a list of "respawn" jobs to watch over durring a read-extract phase, and uses this table to maintain state. If this were not the case it would have to rescan every time a zombie or defunct processess exited. Init only scans the file after an init or telinit command (Q is the init state which is equal to verify current state). I don't beleive that init even does the periodic stat (like cron) to check for updates. Anyway, I have never had any problem editing inittab, and sysadm ttymgmt dosn't do anything special to guard against tye condition you are fretting over, so I don't think you have anything to worry about. Rob.
wally@cbnewsl.ATT.COM (Brian S Walden) (04/07/89)
In article <1166@westmark.UUCP>, dave@westmark.UUCP (Dave Levenson) writes: > When is it ever safe to edit /etc/inittab when UNIX is running? This works for me: # cp /etc/inittab /etc/Ninittab # ed /etc/Ninittab # ln /etc/inittab /etc/Oinittab # mv /etc/Ninittab /etc/inittab # init q The only time /etc/inittab might not be found is in the mv (not too likely), and you have a backup of your old one. Questions about it killing children when inittab is not found: if /etc/inittab is not found by init, nothing should happen to any of it's children (but will spew out to the console that /etc/inittab is not found). When /etc/inittab reappears, it will bump off all your users. (This is true with SVR2) -- Brian S Walden AT&T Bell Labs, Whippany, NJ att!attbl!brian.s.walden