From: NU013809@NDSUVM1.BITNET (Greg Wettstein) Subject: Re: SYS/V init refuses to run my /etc/rc Date: 28 Jan 1993 13:31:46 GMT
..... This damnable mainframe, doesn't recognize backspace, sorry about
accidentally sending the first part of this message.
Anyway I was saying that I uncovered this problem when I modified the
networking daemons (named, inetd etc) so that they could be controlled by
init. I chased a problem with named starting up but refusing to function
which I traced back to this problem with not getting all file descriptors
closed and inconsistent use of the setsid() call.
After these problems I decided to give the sysvinit package a try and after
some modifications have decided to use this as our init base at the Center.
There were a couple of bugs, notably one in which all the open file
descriptors were not closed after init forked a desired process but I am
sure Michael know's about these. He had mentioned last week that a new
version would be coming out soon that addressed a number of bugs.
One thing that I did like about the bootsys package was the fact that it
provided the disk sync daemon internally as part of init. I always like to
reduce parts count so I modified the sysvinit package to provide a similar
service.
In order to do this without breaking the child wait and general sleep code I
implemented a new alarm scheduler that allows init to track multiple alarm
sources. It seems to be working well after about a week of fairly intensive
testing on our development machines.
I also converted the warning/logging code in the sysvinit package to use
syslog facilities. As long as I was hacking I also made a somewhat
egregious modification which allows init to modify its command line
arguements to show the current run-level being held by init. I am not much
for this type of thing since modification of command-line arguements is
something not well-defined across systems. Since init is going to be pretty
specific for Linux I thought what the heck. The upshot of this modification
is that a ps -aux will show what run-level the system is at.
N.B.: I was wondering what people would think of providing for proctitle
support in the kernel. There are a number of things which would benefit
from a 'standardized' method of modifying the command arguements held in the
kernel's task structure.
None of this is meant to cast a shadow on either of the two init packages.
Working with both of them leaves me with the impression that the authors
spent considerable amounts of time on their respective implementations.
Hopefully some of my experiences will save other's frustration.
As always,
Dr. G.W. Wettstein
Oncology Research Division Computing Facility
Fargo Clinic / MeritCare
UUCP: uunet!plains!wind!greg
INTERNET: greg%wind.uucp@plains.nodak.edu
Phone: 701-234-2833
`The truest mark of a man's wisdom is his ability to listen to other
men expound their wisdom.'