Subba Rao <firstname.lastname@example.org>:
> I am trying to add a process which is to be managed by init. I have added the
> following entry to /etc/inittab
> SV:2345:respawn:env - PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin svscan /service </dev/null 2> dev/console
> After saving, I execute the following command:
> # kill -HUP 1
> This does not start the process I have added. The process that I have added
> only starts when I do:
> # init u
> # telinit u
> PS - The process will not start even after a reboot. I have to manually do one
> of the above commands as root.
> My kernel version is : 2.2.19
> Distro : Slackware
> GCC : gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> Any help appreciated.
I'm using Slackware 7.1, so one of the following possible solutions may work:
Make sure the daemon is available at boot time - if /usr/local/bin is
where the svscan daemon exists, then /usr/local must be part of the
root file system.
What I do is have a "/host" directory tree on the root file system
for this purpose. Alternatively, I start the daemon when the system
enters multi-user mode (either /etc/rc.d/rc.local, or one of the
already existing scripts related to what the daemon does).
A second possibility (try this first - its easer:
I see that the daemon is to run in modes "2345". There is a possiblity
that you have this entry near the beginning of the inittab. If so, try
putting it at the end. I believe that init runs each line of the
inittab for a given run level in the same order that it appears in the
file. Putting the entry last should allow it to be started AFTER
all file systems are mounted - the entry for multiuser mode is:
# Script to run when going multi user.
If your daemon entry follows this line then it may work as you
Remember, any facility that the daemon depends on must be
initialized before the daemon starts - If it uses the network
then the network needs to be loaded (mine needs sockets loaded...)
before the daemon is started.
Note: since the assumption that the daemon is in /usr/local and
that /usr/local is a separate file system is true, then
you will no longer be able to dismount the /usr/local
file system while in multi-user mode (it's busy). This may
only be relevent to how your backups are done.
BTW, SIGHUP may not be the correct signal - from the init manpage:
Init looks for /etc/initrunlvl and /var/log/initrun-
lvl. If one of these files exist and contain an
ASCII runlevel, init switches to the new runlevel.
This is for backwards compatibility only! . In the
normal case (the files don't exist) init behaves like
telinit q was executed.
The only documented startup is "init u" or "telinit u". To re-read the
inittab file use "init q" or "telinit q". I suspect the manpage is a
little "inaccurate" in stating that SIGHUP is equivalent to "telinit q"
Jesse I Pollard, II
Any opinions expressed are solely my own.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:17 EST