Newsgroups: comp.os.linux
Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!
ghost.dsi.unimi.it!rpi!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!
yale!gumby!destroyer!news.iastate.edu!hobbes.physics.uiowa.edu!
moe.ksu.ksu.edu!engr.uark.edu!tep
From: t...@engr.uark.edu (Tim Peoples)
Subject: SYS/V init refuses to run my /etc/rc
Message-ID: <1993Jan27.164249.29307@engr.uark.edu>
Summary: It just won't do it...
Keywords: init rc
Sender: netn...@engr.uark.edu (NetNews Administrator)
Nntp-Posting-Host: engr.uark.edu
Reply-To: t...@engr.uark.edu
Organization: University of Arkansas
Organiztion: University of Arkansas, Dept. of Computer Systems Engineering
Date: Wed, 27 Jan 1993 16:42:49 GMT
Lines: 21
I have recently installed the Sys/V init package but every time I
boot my machine I get message from init saying that it can't execute
my /etc/rc. My inittab entry for /etc/rc is taked directly from the
example inittab that came with the package.
I sure could use some help on this one....I hate having to run rc
by hand.
NOTE: I'm running 0.97.4 (I know ... it's high time I upgraded)
--
+--------------------------------------+-------------------------------------+
| Tim Peoples | The time has come the hacker said |
| t...@engr.uark.edu | to talk of many things, |
| Dept. of Computer Systems Engineering| of simms and sockets and semaphores |
| University of Arkansas, Fayetteville | of processes and pings.... |
+--------------------------------------+-------------------------------------+
| I need no disclaimer; nobody listens to what I have to say anyway!! |
+----------------------------------------------------------------------------+
Path: sparky!uunet!math.fu-berlin.de!ira.uka.de!scsing.switch.ch!
univ-lyon1.fr!ghost.dsi.unimi.it!rpi!usenet.coe.montana.edu!
news.u.washington.edu!ns1.nodak.edu!plains!ndsuvm1!nu013809
From: NU013...@NDSUVM1.BITNET (Greg Wettstein)
Newsgroups: comp.os.linux
Subject: Re: SYS/V init refuses to run my /etc/rc
Message-ID: <93028.072408NU013809@NDSUVM1.BITNET>
Date: 28 Jan 93 13:24:08 GMT
References: <1993Jan27.164249.29307@engr.uark.edu>
<1993Jan28.082729.11300@aixrs0.hrz.uni-essen.de>
Organization: North Dakota Higher Education Computer Network
Lines: 26
I just spent about a week getting the run-level init problem solved on
our network. Previously we had been using the simpleinit but it was
time to move onward. Perhaps I can save people some frustration.
I started with the bootsys3 package but moved over to Michael's sysvinit
after about 24 hours of work. Mike Jagdis is to be complimented on
putting together a nice package but the actual init code needs some
attention.
The first problem is that init will not properly read its inittab file.
This is difficult to notice because the fairly complex system of
initialization files and such seems to mask this basic dysfunctionality.
It took me awhile to figure out what was going on because there is a bug
in the processing of the telinit command options which prevents the user
from ordering a re-read of the inittab file (telinit q). The actual
bug in the parsing of the inittab file is only about a one or two line
patch.
The proper parenting and establishment of session ID's is another story.
This is compounded by the fact that the syslog code in the 4.2 libraries
does not properly set the NOCTTY flag. Mike J has fixed this in his
port of the syslogd daemon but the problem still exists in the libraries.
The long and short of this is that you will sometimes end up with getty's
hooked up to the console (/dev/console) and sometimes without any
controlling tty's whatsoever. I actually stumbled onto this when I
modified the networking daemons so not
Path: sparky!uunet!math.fu-berlin.de!ira.uka.de!scsing.switch.ch!
univ-lyon1.fr!ghost.dsi.unimi.it!rpi!usenet.coe.montana.edu!
news.u.washington.edu!ns1.nodak.edu!plains!ndsuvm1!nu013809
From: NU013...@NDSUVM1.BITNET (Greg Wettstein)
Newsgroups: comp.os.linux
Subject: Re: SYS/V init refuses to run my /etc/rc
Message-ID: <93028.073146NU013809@NDSUVM1.BITNET>
Date: 28 Jan 93 13:31:46 GMT
References: <1993Jan27.164249.29307@engr.uark.edu>
<1993Jan28.082729.11300@aixrs0.hrz.uni-essen.de>
Organization: North Dakota Higher Education Computer Network
Lines: 57
..... 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.u...@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.'