Startup service

Startup service

Post by Darre » Mon, 30 Apr 2001 03:06:01



Hello all I am writing a small app that I want to run as a Linux service
when it starts up. Can anyone tell me if I need any special consideration
when writing a Linux tsr? also does one know which file it stores the info
on startup apps in?

Thank you

Darren

 
 
 

Startup service

Post by D. Stimit » Mon, 30 Apr 2001 06:23:29



> Hello all I am writing a small app that I want to run as a Linux service
> when it starts up. Can anyone tell me if I need any special consideration
> when writing a Linux tsr? also does one know which file it stores the info
> on startup apps in?

> Thank you

> Darren

There isn't really anything called a tsr in linux. It is just a daemon.
The typical daemon does a fork and exec after being started by an rc
script. For redhat, the script samples are in /etc/rc.d/init.d/. For
other distributions, they are in an init.d directory, but it might be
located somewhere else; I think SuSE uses /sbin/init.d/ or something
like that. Programs that are not really system daemons but are desired
to start each reboot often are just added in by editing
/etc/rc.d/rc.local (again, location will vary with distribution, but it
is usually named rc.local). SuSE also has an rc script in /etc/ that
yast uses.

The scripts usually take arguments of "start", "stop", "status", and
"restart". Symbolic links from various runlevel directories (e.g.,
/etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
process at those levels, but if the sym link is done with a name
starting with "s" it starts it at that level (your mileage may vary
depending on distribution). Other complexities are that for security it
isn't unusual to arrange for the daemon to start as root but to be
transferred for execution as user "nobody" (or some other less
privileged user); and there is often some sort of lock file or pid file
to let the system know what pid the process is at.



 
 
 

Startup service

Post by Darre » Mon, 30 Apr 2001 06:57:37




> > Hello all I am writing a small app that I want to run as a Linux service
> > when it starts up. Can anyone tell me if I need any special
consideration
> > when writing a Linux tsr? also does one know which file it stores the
info
> > on startup apps in?

> > Thank you

> > Darren

> There isn't really anything called a tsr in linux. It is just a daemon.

that would be typical of linux. so smooth and consistent :-)

Quote:> The typical daemon does a fork and exec after being started by an rc
> script.

whats the differece between a fork and an exec?

For redhat, the script samples are in /etc/rc.d/init.d/. For

Quote:> other distributions, they are in an init.d directory, but it might be
> located somewhere else; I think SuSE uses /sbin/init.d/ or something
> like that. Programs that are not really system daemons but are desired
> to start each reboot often are just added in by editing
> /etc/rc.d/rc.local (again, location will vary with distribution, but it
> is usually named rc.local). SuSE also has an rc script in /etc/ that
> yast uses.

aha so it is rc.local i am looking for?

Quote:

> The scripts usually take arguments of "start", "stop", "status", and
> "restart". Symbolic links from various runlevel directories (e.g.,
> /etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
> process at those levels,

forgive me for being stupid, but i do not understand

but if the sym link is done with a name

Quote:> starting with "s" it starts it at that level (your mileage may vary
> depending on distribution). Other complexities are that for security it
> isn't unusual to arrange for the daemon to start as root but to be
> transferred for execution as user "nobody" (or some other less
> privileged user);

now this i understand. I do have need to have a process start at bootup and
as all processes need a user connection then i need to create a virual user
with priviledges to access only the required reources and attach the process
to that user, if that makes any sense

 and there is often some sort of lock file or pid file

Quote:> to let the system know what pid the process is at.

Thank you for your reply D you have been most kind



 
 
 

Startup service

Post by Cameron Ker » Mon, 30 Apr 2001 09:54:16


<snip>

Quote:> whats the differece between a fork and an exec?

Fork creates a child process. The created process is the
same as the creating process, with no shared state, and
same instruction pointers etc.

Exec is used to replace the current process (usually in
the child) with another process, overwriting the current
process. No new process is created.

<snip>

Quote:> aha so it is rc.local i am looking for?

If you want to create a standalone deamon. If you want
the internet super-server (inetd or xinetd), it is much
easier. You just write your program to use stdin and stdout
as the input/output to the client. You then edit
/etc/inetd.conf or /etc/xinetd.{conf|d/*} and restart
the super-server by sending the -HUP signal

killall -HUP inetd

Quote:>> The scripts usually take arguments of "start", "stop", "status", and
>> "restart". Symbolic links from various runlevel directories (e.g.,
>> /etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
>> process at those levels,
> forgive me for being stupid, but i do not understand

Virtually all GNU/Linux systems have a concept of
"runlevels" (this is a System V concept). Runlevel
0 means "system shutdown", 6 means "system restart",
1 means "single user", 3 is typically "multiuser without
the X Window System", 4 or 5 is usually the same as 3, but
with GUI. Some of this is distribution independant. Look
in /etc/inittab for the*details.

Anyway, on systems with SysV style setups (most), when
a runlevel is changed, services are started or stopped
according to the various symlinks. The best way to find
out would be to look for yourself (try /etc/rc.d/rc[0123456].d/
in Redhat. The system will automatically append "start"
or "stop" to services that it needs to start or stop.

In all, I suggest you read the following

The GNU libc manual (ftp.gnu.org/gnu/Manuals/glibc)
The Linux Programmers Guide (www.linuxdoc.org/guides)
And constantly be on the lookout for any useful articles
that teach you about certain things. You might find
www.ibm.com :: Developer :: Linux :: Linux Articles
useful. Also www.google.com :: Web directory :: * :: Linux ::
Resources would be useful to you.

Hope this helps
--

Praise Slackware, our baud and saviour!
--

 
 
 

Startup service

Post by D. Stimit » Tue, 01 May 2001 13:00:54


Someone else already answered this, but I thought it might be useful to
add to it.





> > > Hello all I am writing a small app that I want to run as a Linux service
> > > when it starts up. Can anyone tell me if I need any special
> consideration
> > > when writing a Linux tsr? also does one know which file it stores the
> info
> > > on startup apps in?

> > > Thank you

> > > Darren

> > There isn't really anything called a tsr in linux. It is just a daemon.

> that would be typical of linux. so smooth and consistent :-)

It does make programming and debugging easier.

Quote:

> > The typical daemon does a fork and exec after being started by an rc
> > script.
> whats the differece between a fork and an exec?

> For redhat, the script samples are in /etc/rc.d/init.d/. For
> > other distributions, they are in an init.d directory, but it might be
> > located somewhere else; I think SuSE uses /sbin/init.d/ or something
> > like that. Programs that are not really system daemons but are desired
> > to start each reboot often are just added in by editing
> > /etc/rc.d/rc.local (again, location will vary with distribution, but it
> > is usually named rc.local). SuSE also has an rc script in /etc/ that
> > yast uses.

> aha so it is rc.local i am looking for?

If your only concern is to run some command at startup, yes. If it must
be controlled for start and stop activity at various runlevels, you'd
create a script to go in the init.d subdirectory; then links from the
various runlevel directories would determine whether the script is
called with a start or stop at the given runlevels. inetd is a sample of
something controlled at various runlevels, as well as a few other
daemons. To see a list of what is controlled to start or stop, try this:
chkconfig --list
(chkconfig might not be available under all distributions, I haven't
checked)

Quote:

> > The scripts usually take arguments of "start", "stop", "status", and
> > "restart". Symbolic links from various runlevel directories (e.g.,
> > /etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
> > process at those levels,
> forgive me for being stupid, but i do not understand

UNIX-style systems do not simply boot up or stop, they start or stop in
stages. Stopped appears to always be runlevel 0, reboot runlevel 6. In
between there is usually a single user mode (console only single user,
good for some forms of disaster recovery), a multi-user console mode,
and a multi-user graphics mode (X11). The exact number used for those in
between levels varies with distribution. Sometimes there is further
breakdown, such as single user console mode without networking, and the
next mode up being single user still but with networking. If you use
something like "ps aux" you will see process ID 1 is the grand parent of
all processes, "init". The runlevel is the argument to init. If root
calls "init 6", it will reboot; if root calls "init 0", it will halt.
The startup scripts are calling init in a series of steps, and at each
step, running scripts from init.d to start or stop services scheduled
for those levels. rc.local is generally the last thing called in the
bootup final runlevel destination, whereas init.d scripts can be
automatically called with start or stop arguments at every level. Thus,
if you only want to end up running something at the final bootup level,
just add it to rc.local; if you want to make sure about a specific start
or stop behaviour at each runlevel, put it in the init.d subdirectory
and create the appropriate links (chkconfig can do this for you, take a
look at the top comments in the init.d scripts).

As an example, on redhat, if you have the cron daemon to run, root can
type any of these:
/etc/rc.d/init.d/crond status
(returns its current status)

/etc/rc.d/init.d/crond stop
(stops cron daemon; error if it wasn't started already)

/etc/rc.d/init.d/crond start
(starts cron daemon; error if it was already started)

/etc/rc.d/init.d/crond restart
(stops then starts the cron daemon; error if it wasn't already started)

On one redhat 6.2 system, "chkconfig --list | grep crond" shows this:
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off

This means that at runlevels 0, 1, and 6, crond is turned off, while
runlevels 2, 3, 4, and 5 have it turned on. For redhat, runlevel 4 is
never used, so it is actually irrelevant.

Quote:

> but if the sym link is done with a name
> > starting with "s" it starts it at that level (your mileage may vary
> > depending on distribution). Other complexities are that for security it
> > isn't unusual to arrange for the daemon to start as root but to be
> > transferred for execution as user "nobody" (or some other less
> > privileged user);
> now this i understand. I do have need to have a process start at bootup and
> as all processes need a user connection then i need to create a virual user
> with priviledges to access only the required reources and attach the process
> to that user, if that makes any sense

Yes, a lot of startup daemons are started by root, but transferred to
ownership by a less privileged user. In terms of security, explicit
testing and start or stop at each runlevel is probably the better way to
go, versus rc.local, but as an end result you could do it either way
(with rc.local being less complicated).


- Show quoted text -

>  and there is often some sort of lock file or pid file
> > to let the system know what pid the process is at.

> Thank you for your reply D you have been most kind



 
 
 

Startup service

Post by Darre » Tue, 01 May 2001 17:45:50



Quote:> Someone else already answered this, but I thought it might be useful to
> add to it.

all input is welcome





> > > > Hello all I am writing a small app that I want to run as a Linux
service
> > > > when it starts up. Can anyone tell me if I need any special
> > consideration
> > > > when writing a Linux tsr? also does one know which file it stores
the
> > info
> > > > on startup apps in?

> > > > Thank you

> > > > Darren

> > > There isn't really anything called a tsr in linux. It is just a
daemon.

> > that would be typical of linux. so smooth and consistent :-)

> It does make programming and debugging easier.

yes

- Show quoted text -

Quote:

> > > The typical daemon does a fork and exec after being started by an rc
> > > script.
> > whats the differece between a fork and an exec?

> > For redhat, the script samples are in /etc/rc.d/init.d/. For
> > > other distributions, they are in an init.d directory, but it might be
> > > located somewhere else; I think SuSE uses /sbin/init.d/ or something
> > > like that. Programs that are not really system daemons but are desired
> > > to start each reboot often are just added in by editing
> > > /etc/rc.d/rc.local (again, location will vary with distribution, but
it
> > > is usually named rc.local). SuSE also has an rc script in /etc/ that
> > > yast uses.

> > aha so it is rc.local i am looking for?

> If your only concern is to run some command at startup, yes.

it is mainly

If it must

Quote:> be controlled for start and stop activity at various runlevels, you'd
> create a script to go in the init.d subdirectory; then links from the
> various runlevel directories would determine whether the script is
> called with a start or stop at the given runlevels. inetd is a sample of
> something controlled at various runlevels, as well as a few other
> daemons. To see a list of what is controlled to start or stop, try this:
> chkconfig --list
> (chkconfig might not be available under all distributions, I haven't
> checked)

i have redhat 5.2

Quote:

> > > The scripts usually take arguments of "start", "stop", "status", and
> > > "restart". Symbolic links from various runlevel directories (e.g.,
> > > /etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
> > > process at those levels,

cool.

Quote:> > forgive me for being stupid, but i do not understand

> UNIX-style systems do not simply boot up or stop, they start or stop in
> stages. Stopped appears to always be runlevel 0, reboot runlevel 6. In
> between there is usually a single user mode (console only single user,
> good for some forms of disaster recovery), a multi-user console mode,
> and a multi-user graphics mode (X11). The exact number used for those in
> between levels varies with distribution. Sometimes there is further
> breakdown, such as single user console mode without networking, and the
> next mode up being single user still but with networking. If you use
> something like "ps aux" you will see process ID 1 is the grand parent of
> all processes, "init". The runlevel is the argument to init. If root
> calls "init 6", it will reboot; if root calls "init 0", it will halt.

aha, now i see :-)

Quote:> The startup scripts are calling init in a series of steps, and at each
> step, running scripts from init.d to start or stop services scheduled
> for those levels. rc.local is generally the last thing called in the
> bootup final runlevel destination, whereas init.d scripts can be
> automatically called with start or stop arguments at every level. Thus,
> if you only want to end up running something at the final bootup level,
> just add it to rc.local; if you want to make sure about a specific start
> or stop behaviour at each runlevel, put it in the init.d subdirectory

I get you! this is so cool! Linux is a babe!!!!

- Show quoted text -

Quote:> and create the appropriate links (chkconfig can do this for you, take a
> look at the top comments in the init.d scripts).

> As an example, on redhat, if you have the cron daemon to run, root can
> type any of these:
> /etc/rc.d/init.d/crond status
> (returns its current status)

> /etc/rc.d/init.d/crond stop
> (stops cron daemon; error if it wasn't started already)

> /etc/rc.d/init.d/crond start
> (starts cron daemon; error if it was already started)

> /etc/rc.d/init.d/crond restart
> (stops then starts the cron daemon; error if it wasn't already started)

> On one redhat 6.2 system, "chkconfig --list | grep crond" shows this:
> crond          0:off 1:off 2:on 3:on 4:on 5:on 6:off

> This means that at runlevels 0, 1, and 6, crond is turned off, while
> runlevels 2, 3, 4, and 5 have it turned on. For redhat, runlevel 4 is
> never used, so it is actually irrelevant.

aha

- Show quoted text -

> > but if the sym link is done with a name
> > > starting with "s" it starts it at that level (your mileage may vary
> > > depending on distribution). Other complexities are that for security
it
> > > isn't unusual to arrange for the daemon to start as root but to be
> > > transferred for execution as user "nobody" (or some other less
> > > privileged user);
> > now this i understand. I do have need to have a process start at bootup
and
> > as all processes need a user connection then i need to create a virual
user
> > with priviledges to access only the required reources and attach the
process
> > to that user, if that makes any sense

> Yes, a lot of startup daemons are started by root, but transferred to
> ownership by a less privileged user. In terms of security, explicit
> testing and start or stop at each runlevel is probably the better way to
> go, versus rc.local, but as an end result you could do it either way
> (with rc.local being less complicated).



Thanks you have been very helpful.

- Show quoted text -

> >  and there is often some sort of lock file or pid file
> > > to let the system know what pid the process is at.

> > Thank you for your reply D you have been most kind



 
 
 

Startup service

Post by Darre » Tue, 01 May 2001 17:46:50



Quote:> <snip>

> > whats the differece between a fork and an exec?

> Fork creates a child process. The created process is the
> same as the creating process, with no shared state, and
> same instruction pointers etc.

> Exec is used to replace the current process (usually in
> the child) with another process, overwriting the current
> process. No new process is created.

> <snip>

> > aha so it is rc.local i am looking for?

> If you want to create a standalone deamon. If you want
> the internet super-server (inetd or xinetd), it is much
> easier. You just write your program to use stdin and stdout
> as the input/output to the client. You then edit
> /etc/inetd.conf or /etc/xinetd.{conf|d/*} and restart
> the super-server by sending the -HUP signal

> killall -HUP inetd

> >> The scripts usually take arguments of "start", "stop", "status", and
> >> "restart". Symbolic links from various runlevel directories (e.g.,
> >> /etc/rc.d/rc.0 through rc.6) named starting with a "k" will kill the
> >> process at those levels,
> > forgive me for being stupid, but i do not understand

> Virtually all GNU/Linux systems have a concept of
> "runlevels" (this is a System V concept). Runlevel
> 0 means "system shutdown", 6 means "system restart",
> 1 means "single user", 3 is typically "multiuser without
> the X Window System", 4 or 5 is usually the same as 3, but
> with GUI. Some of this is distribution independant. Look
> in /etc/inittab for the*details.

> Anyway, on systems with SysV style setups (most), when
> a runlevel is changed, services are started or stopped
> according to the various symlinks. The best way to find
> out would be to look for yourself (try /etc/rc.d/rc[0123456].d/
> in Redhat. The system will automatically append "start"
> or "stop" to services that it needs to start or stop.

> In all, I suggest you read the following

> The GNU libc manual (ftp.gnu.org/gnu/Manuals/glibc)
> The Linux Programmers Guide (www.linuxdoc.org/guides)
> And constantly be on the lookout for any useful articles
> that teach you about certain things. You might find
> www.ibm.com :: Developer :: Linux :: Linux Articles
> useful. Also www.google.com :: Web directory :: * :: Linux ::
> Resources would be useful to you.

> Hope this helps

it does. Thank you Cameron
 
 
 

Startup service

Post by Xiaomu Zen » Fri, 04 May 2001 00:54:25



> > aha so it is rc.local i am looking for?

> If your only concern is to run some command at startup, yes. If it must
> be controlled for start and stop activity at various runlevels, you'd
> create a script to go in the init.d subdirectory; then links from the
> various runlevel directories would determine whether the script is
> called with a start or stop at the given runlevels. inetd is a sample of
> something controlled at various runlevels, as well as a few other
> daemons. To see a list of what is controlled to start or stop, try this:
> chkconfig --list
> (chkconfig might not be available under all distributions, I haven't
> checked)

So rc.local will always be ran, at any init level (even single user mode)?

Xiaomu

 
 
 

Startup service

Post by Darre » Fri, 04 May 2001 09:40:00




> > > aha so it is rc.local i am looking for?

> > If your only concern is to run some command at startup, yes. If it must
> > be controlled for start and stop activity at various runlevels, you'd
> > create a script to go in the init.d subdirectory; then links from the
> > various runlevel directories would determine whether the script is
> > called with a start or stop at the given runlevels. inetd is a sample of
> > something controlled at various runlevels, as well as a few other
> > daemons. To see a list of what is controlled to start or stop, try this:
> > chkconfig --list
> > (chkconfig might not be available under all distributions, I haven't
> > checked)

> So rc.local will always be ran, at any init level (even single user mode)?

> Xiaomu

cool

- Show quoted text -

 
 
 

Startup service

Post by D. Stimit » Fri, 04 May 2001 12:51:19




> > > aha so it is rc.local i am looking for?

> > If your only concern is to run some command at startup, yes. If it must
> > be controlled for start and stop activity at various runlevels, you'd
> > create a script to go in the init.d subdirectory; then links from the
> > various runlevel directories would determine whether the script is
> > called with a start or stop at the given runlevels. inetd is a sample of
> > something controlled at various runlevels, as well as a few other
> > daemons. To see a list of what is controlled to start or stop, try this:
> > chkconfig --list
> > (chkconfig might not be available under all distributions, I haven't
> > checked)

> So rc.local will always be ran, at any init level (even single user mode)?

> Xiaomu

I have not actually tested to give you an answer. It does not use the
normal runlevel scripting, so I believe it likely does (without looking
I am guessing that the rc main init script always calls rc.local once it
has finished the last runlevel it is aiming for, aside from shutdown).
The way to test it would be to add a line to rc.local such as:
echo "rc.local has run" > /tmp/rc.test.txt

Make sure that file is empty and try rebooting to single user mode. If
the file /tmp/rc.test.txt has "rc.local has run" in it, then it ran;
otherwise not. rc.local does definitely run at normal multiuser console
and graphics mode.


 
 
 

Startup service

Post by Kasper Dupon » Fri, 04 May 2001 18:35:28





> > > > aha so it is rc.local i am looking for?

> > > If your only concern is to run some command at startup, yes. If it must
> > > be controlled for start and stop activity at various runlevels, you'd
> > > create a script to go in the init.d subdirectory; then links from the
> > > various runlevel directories would determine whether the script is
> > > called with a start or stop at the given runlevels. inetd is a sample of
> > > something controlled at various runlevels, as well as a few other
> > > daemons. To see a list of what is controlled to start or stop, try this:
> > > chkconfig --list
> > > (chkconfig might not be available under all distributions, I haven't
> > > checked)

> > So rc.local will always be ran, at any init level (even single user mode)?

> > Xiaomu

> I have not actually tested to give you an answer. It does not use the
> normal runlevel scripting, so I believe it likely does (without looking
> I am guessing that the rc main init script always calls rc.local once it
> has finished the last runlevel it is aiming for, aside from shutdown).
> The way to test it would be to add a line to rc.local such as:
> echo "rc.local has run" > /tmp/rc.test.txt

> Make sure that file is empty and try rebooting to single user mode. If
> the file /tmp/rc.test.txt has "rc.local has run" in it, then it ran;
> otherwise not. rc.local does definitely run at normal multiuser console
> and graphics mode.



This command will tell you in which runlevels rc.local
will be executed:

ls -l /etc/rc.d/*/*local*

The sequence of actions during startup is the following:
the init program /sbin/init will load a configuration
file from /etc/inittab. The configuration file will tell
init to execute /etc/rc.d/rc, this script will execute
all start scripts from the appropriate runlevel directory.

--
Kasper Dupont

 
 
 

Startup service

Post by Darre » Fri, 04 May 2001 22:26:20






> > > > > aha so it is rc.local i am looking for?

> > > > If your only concern is to run some command at startup, yes. If it
must
> > > > be controlled for start and stop activity at various runlevels,
you'd
> > > > create a script to go in the init.d subdirectory; then links from
the
> > > > various runlevel directories would determine whether the script is
> > > > called with a start or stop at the given runlevels. inetd is a
sample of
> > > > something controlled at various runlevels, as well as a few other
> > > > daemons. To see a list of what is controlled to start or stop, try
this:
> > > > chkconfig --list
> > > > (chkconfig might not be available under all distributions, I haven't
> > > > checked)

> > > So rc.local will always be ran, at any init level (even single user
mode)?

> > > Xiaomu

> > I have not actually tested to give you an answer. It does not use the
> > normal runlevel scripting, so I believe it likely does (without looking
> > I am guessing that the rc main init script always calls rc.local once it
> > has finished the last runlevel it is aiming for, aside from shutdown).
> > The way to test it would be to add a line to rc.local such as:
> > echo "rc.local has run" > /tmp/rc.test.txt

> > Make sure that file is empty and try rebooting to single user mode. If
> > the file /tmp/rc.test.txt has "rc.local has run" in it, then it ran;
> > otherwise not. rc.local does definitely run at normal multiuser console
> > and graphics mode.


> This command will tell you in which runlevels rc.local
> will be executed:

> ls -l /etc/rc.d/*/*local*

> The sequence of actions during startup is the following:
> the init program /sbin/init will load a configuration
> file from /etc/inittab. The configuration file will tell
> init to execute /etc/rc.d/rc, this script will execute
> all start scripts from the appropriate runlevel directory.

cool. I have been playing and found the files you mention. I even set my
startup script to welcome me to my pc.. Sad huh? :-)
 
 
 

Startup service

Post by D. Stimit » Sat, 05 May 2001 16:59:20






> > > > > aha so it is rc.local i am looking for?

> > > > If your only concern is to run some command at startup, yes. If it must
> > > > be controlled for start and stop activity at various runlevels, you'd
> > > > create a script to go in the init.d subdirectory; then links from the
> > > > various runlevel directories would determine whether the script is
> > > > called with a start or stop at the given runlevels. inetd is a sample of
> > > > something controlled at various runlevels, as well as a few other
> > > > daemons. To see a list of what is controlled to start or stop, try this:
> > > > chkconfig --list
> > > > (chkconfig might not be available under all distributions, I haven't
> > > > checked)

> > > So rc.local will always be ran, at any init level (even single user mode)?

> > > Xiaomu

> > I have not actually tested to give you an answer. It does not use the
> > normal runlevel scripting, so I believe it likely does (without looking
> > I am guessing that the rc main init script always calls rc.local once it
> > has finished the last runlevel it is aiming for, aside from shutdown).
> > The way to test it would be to add a line to rc.local such as:
> > echo "rc.local has run" > /tmp/rc.test.txt

> > Make sure that file is empty and try rebooting to single user mode. If
> > the file /tmp/rc.test.txt has "rc.local has run" in it, then it ran;
> > otherwise not. rc.local does definitely run at normal multiuser console
> > and graphics mode.


> This command will tell you in which runlevels rc.local
> will be executed:

> ls -l /etc/rc.d/*/*local*

> The sequence of actions during startup is the following:
> the init program /sbin/init will load a configuration
> file from /etc/inittab. The configuration file will tell
> init to execute /etc/rc.d/rc, this script will execute
> all start scripts from the appropriate runlevel directory.

> --
> Kasper Dupont

At first I had not noticed that rc.local was itself called from the same
rc symbolic links. The difference is that most daemons and other items
that are started this way are pointed to in the init.d subdirectory,
whereas rc.local is linked to directly in the parent. This appears to be
enough to keep it out of the usual chkconfig --list display.


 
 
 

1. Startup Services

Sys Mandrake8.0

I want xscreensaver to run whenever I launch KDE.
Created file .xinitrc and put in it:
cat .xinitrc
startkde &
xscreensaver &
imwheel &

This does not work as I have to launch xscreensaver to get it to work.

What do I need to do?
Marvin

2. PNP Soundblaster 16

3. startup service

4. CD-ROM eject/load problems

5. Startup services. . . .

6. Win Mosiac and 1.1.13

7. Turning off startup services?

8. Fetchmail error in RH 7.2

9. Startup Service in Mandrake.

10. Debian: the right way to disable startup services?

11. Disable Startup Services

12. adding a startup service

13. startup services . . . . (I'm a newbie)