sysvinit start service at bootup

[Marco Moock]

Hello!

I am looking for the documentation where the sysvinit system of
Slackware is described.

My case is that I have a script to start, stop etc. nscd and I want to
start that together with the other stuff at the right time (which
runlevel is reasonable?).
I've searched docs.slackware.com, but I can't find an article about
SysVinit there.

[Henrik Carlqvist]

Post by Marco Moock
I am looking for the documentation where the sysvinit system of
Slackware is described.

I think that the right places to start reading would be the man pages of
init and inittab and at the same time studying the files /etc/inittab and
the scripts in /etc/rc.d.

Usually custom or extra calls are added to the files /etc/rc.d/rc.local
and /etc/rc.d/rc.local_shutdown.

The script rc.local is being called during the boot process when going
multiuser which happens in runlevel 2,3,4 and 5.

regards Henrik

[Sam]

Post by Henrik Carlqvist

Post by Marco Moock
I am looking for the documentation where the sysvinit system of
Slackware is described.

I think that the right places to start reading would be the man pages of
init and inittab and at the same time studying the files /etc/inittab and
the scripts in /etc/rc.d.
Usually custom or extra calls are added to the files /etc/rc.d/rc.local
and /etc/rc.d/rc.local_shutdown.
The script rc.local is being called during the boot process when going
multiuser which happens in runlevel 2,3,4 and 5.

The most convenient way of doing this with sysvinit is to drop an executable
script:

S50mystuff

into /etc/rc.d/rc[345].d

(hard links, for run levels 3, 4, and 5, adjust if necessary)

[Marco Moock]

Post by Sam

Post by Henrik Carlqvist

Post by Marco Moock
I am looking for the documentation where the sysvinit system of
Slackware is described.

I think that the right places to start reading would be the man
pages of init and inittab and at the same time studying the files
/etc/inittab and the scripts in /etc/rc.d.
Usually custom or extra calls are added to the files
/etc/rc.d/rc.local and /etc/rc.d/rc.local_shutdown.
The script rc.local is being called during the boot process when
going multiuser which happens in runlevel 2,3,4 and 5.

The most convenient way of doing this with sysvinit is to drop an
S50mystuff

Is it enough if that includes

#/bin/bash
/etc/rc.d/rc.nscd start

Or does it need more?
Do I need a kill script or will it be killed automatically at shutdown?

If I need one, which runlevel would fit?
0?

[noel]

Post by Marco Moock

Post by Sam
The most convenient way of doing this with sysvinit is to drop an
S50mystuff

When I see this I automatically see a redhat or debian user

Post by Marco Moock
Is it enough if that includes
#/bin/bash /etc/rc.d/rc.nscd start
Or does it need more?
Do I need a kill script or will it be killed automatically at shutdown?
If I need one, which runlevel would fit?
0?

just add it to rc.M and be done with it (will work *all run levels 1-6*)

if [ -x /etc/rc.d/rc.nscd ]; then
/etc/rc.d/rc.nscd start
fi


If it cleanly needs to be *shutdown add above but with "stop" to rc.0*

[noel]

Post by noel
just add it to rc.M and be done with it (will work *all run levels 1-6*)

Argg I fat fingered (well its 650am and 5 degrees ATM), its run level
1-5, it covers single, multi console, multi X.

6 and 0 are linked (one os symlinked to the other) for shutdown

[Sylvain Robitaille]

Post by noel
Argg I fat fingered (well its 650am and 5 degrees ATM), its run level
1-5, it covers single, multi console, multi X.

Keeping in mind, though, that nscd isn't particularly useful in run
levels 1 and 2 ...

[Sam]

Post by noel

Post by Marco Moock

Post by Sam
The most convenient way of doing this with sysvinit is to drop an
S50mystuff

When I see this I automatically see a redhat or debian user

Maybe one from 10-15 years ago.

Neither Red Hat, nor Debian, works like this, any more.

Post by noel

Post by Marco Moock
Is it enough if that includes
#/bin/bash /etc/rc.d/rc.nscd start
Or does it need more?
Do I need a kill script or will it be killed automatically at shutdown?
If I need one, which runlevel would fit?
0?

just add it to rc.M and be done with it (will work *all run levels 1-6*)

That approach probably works for a one-off situation.

But if there's some anticipation of either:

- updates to new versions of Slackware, at some bright point in the future,

- or installs, or reinstalls, for any one of several different reasons,

Then one wants to have some kind of a reproducible, and automated process.
That is, one that's initiated by a simple, basic command.

Manually editing rc.M is not going to fit the bill.

[noel]

Post by Sam

Post by noel

Post by Marco Moock

Post by Sam
The most convenient way of doing this with sysvinit is to drop an
S50mystuff

When I see this I automatically see a redhat or debian user

Maybe one from 10-15 years ago.
Neither Red Hat, nor Debian, works like this, any more.

Post by noel

Post by Marco Moock
Is it enough if that includes
#/bin/bash /etc/rc.d/rc.nscd start
Or does it need more?
Do I need a kill script or will it be killed automatically at shutdown?
If I need one, which runlevel would fit?
0?

just add it to rc.M and be done with it (will work *all run levels 1-6*)

That approach probably works for a one-off situation.

one off, no, weve used that for nearly 25 years, in production (ISP
environment) on all servers, incl hosting, its the most robust and
effective, a LOT of slackware servers run by others operate the same way.

Post by Sam
- updates to new versions of Slackware, at some bright point in the future,
- or installs, or reinstalls, for any one of several different reasons,

oh, you're only a home user, even then, no, its suitable, rc.M stock,
hasn't changed that much, and keeping all the custom services in same
area makes it simple to include, of course now postfix and dovecot as
stock, some of it is redundant, though we still have pure-ftpd, as well
as a verious other things, like imap-proxy, radius, IRC server, jabber
server, news server :) and no doubt I've forgotten one or two others off
top of my head, so it wont take much to add them back if anythig
catastrophoic occurs, we have however had proprietary software (eg:
billing system ) come with service files and they dont work, so not
always a drop in replacement, so why bother.

Post by Sam
Then one wants to have some kind of a reproducible, and automated
process. That is, one that's initiated by a simple, basic command.
Manually editing rc.M is not going to fit the bill.

scp does.

we have the template for whatever service it is
if its MX-in or smtp we send over that
if its a imap/pop we send over that
web server we send its over, and so on and so on and so on.
...be they repairs (never happened) or adding to the cluster a new.

I'm betting I can commision a new server in same time or better than your
suggested methods.


but hey, OP can run it how he seem fit, thats the best part about
slackware, you tell the OS what you want, not having debian or redhat or
worse - microsoft, dictate what will happen.

[Sylvain Robitaille]

Post by noel
one off, no, weve used that for nearly 25 years, in production (ISP
environment) on all servers, incl hosting, its the most robust and
effective, a LOT of slackware servers run by others operate the same way.

Have you looked into using cfengine in your environment at all? I am
inclined to think that it would help quite a bit with what you're
describing. (and yes, cfengine can be used to add to rc.M in a case
such as this, if the admin so chooses)

[noel]

Post by Sylvain Robitaille

Post by noel
one off, no, weve used that for nearly 25 years, in production (ISP
environment) on all servers, incl hosting, its the most robust and
effective, a LOT of slackware servers run by others operate the same way.

Have you looked into using cfengine in your environment at all? I am
inclined to think that it would help quite a bit with what you're
describing. (and yes, cfengine can be used to add to rc.M in a case
such as this, if the admin so chooses)

Not looked at cfengine, we used to use puppet some time ago, but now all
our servers are uniform (well, service types for service types ) so its
as simple as installing and running our custom script which moves over
appropriate configs for daemons and systems, takes about 30 mins to build
the raid, install the OS and 30 seconds to put in place the server_type
configs, a quick reboot to make sure everything comes up and its
provisioned ready to do what ever service it was installed for- typcially
web, since we have ample DNS, smtp, mx, imap/pop3's ... and so on.

[Sylvain Robitaille]

Post by noel
Not looked at cfengine, we used to use puppet some time ago, but now
all our servers are uniform (well, service types for service types )
so its as simple as installing and running our custom script which
moves over appropriate configs for daemons and systems, ...

You've certainly streamlined things well for your own workflow, but
for what it's worth, what you're describing is indeed something that
cfengine is good at: "this is a $foo server, so $bar configurations
must be addressed." If what you're already doing works as well as
you describe, though, I certainly wouldn't be looking to replace it
either ...

[noel]

Post by Sam
The most convenient way of doing this with sysvinit is to drop an
S50mystuff

Forgot to comment on this, so where do you think you're going to get this
"drop in" file from? you typcially have to create it, unless you're
limiting yourself to miniscule subset of daemons that are released with
them.

[Sam]

Post by noel

Post by Sam
The most convenient way of doing this with sysvinit is to drop an
S50mystuff

Forgot to comment on this, so where do you think you're going to get this
"drop in" file from? you typcially have to create it, unless you're
limiting yourself to miniscule subset of daemons that are released with
them.

This is what packages are for.

A slackware package can certainly drop a file in there.

Instead of manually editing a file, a package containing the software to
install, gets prepared, tested in non-production, and once QA is passed it
gets deployed to production servers, instead of manually firing up vi and
hoping that your fingers do the right thing. The package installs the
software, together with everything that's needed to launch it at system boot.

Now, I do understand that many people are quite comfortable with manually
editing and hacking initscripts. If it works for them, wonderful. But this
doesn't really work in situations where human error must be minimized to the
greatest extent possible.

[noel]

Post by Sam
Instead of manually editing a file, a package containing the software to
install, gets prepared, tested in non-production, and once QA is passed
it gets deployed to production servers, instead of manually firing up vi
and hoping that your fingers do the right thing. The package installs
the software, together with everything that's needed to launch it at
system boot.
Now, I do understand that many people are quite comfortable with
manually editing and hacking initscripts. If it works for them,
wonderful. But this doesn't really work in situations where human error
must be minimized to the greatest extent possible.

it does work in those situations, I showed that in a previous post with
how I and my staff use it.
and in 25 plus years of slackware, actually, jesus i'm old, I think it
was 94-ish so thats 30 years of using it, I've NEVER seen a slackware
package EVER use it, the only package is our propriatary billing system,
which is released packaged for RHEL so stands to reason it would use your
little dot dirs, but nothing else I've seen uses them. you seem shit
scared of editing config files or scripting those edits in automation,
perhaps you'd be happier back in RH.

[Sam]

Post by noel
and in 25 plus years of slackware, actually, jesus i'm old, I think it
was 94-ish so thats 30 years of using it, I've NEVER seen a slackware
package EVER use it, the only package is our propriatary billing system,
which is released packaged for RHEL so stands to reason it would use your
little dot dirs, but nothing else I've seen uses them. you seem shit
scared of editing config files or scripting those edits in automation,
perhaps you'd be happier back in RH.

I spent a great deal of time puzzling over this cryptic reference to "dot
dirs". All I suggested was using "S50mystuff" and installing it in
/etc/rc.d/rc[345].d.

The only common term I'm familiar with is "dot-files", which is an alias for
hidden files, or files whose name begins with a period. It would stand to
reason that dot-dirs would refer to directories whose name also starts with
a period. Unfortunately, an exhaustive search of my proposal was unable to
uncover any reference to such a directory.

I almost decided shrug my shoulders, and write this off with an "Eh, Usenet,
what can you do?" But then it occured to me that you're talking about any
directory whose name includes a period, like rc4.d, for example. Fine, let's
call them "dot-dirs", I'm a very agreeable fellow. Now that this confusion
has been cleared up, I think we can move forward.

You might be surprised to learn that rc4.d, and friends did not originate
"back in RH". And you will be surprised to learn that this directory, and
its cousins also exists on your Slackware box! And not because Slackware
copied it from evil Red Hat, but from Unix.

So Red Hat is a somewhat misplaced target of your scorn, this wasn't a Red
Hat thing, at all. They merely strived to remain compatible until something
better came along (supposedly, but that's an argument for some other time,
and place).

[noel]

Post by Sam

Post by noel
and in 25 plus years of slackware, actually, jesus i'm old, I think it
was 94-ish so thats 30 years of using it, I've NEVER seen a slackware
package EVER use it, the only package is our propriatary billing
system, which is released packaged for RHEL so stands to reason it
would use your little dot dirs, but nothing else I've seen uses them.
you seem shit scared of editing config files or scripting those edits
in automation, perhaps you'd be happier back in RH.

I spent a great deal of time puzzling over this cryptic reference to
"dot dirs". All I suggested was using "S50mystuff" and installing it in
The only common term I'm familiar with is "dot-files", which is an alias
for hidden files, or files whose name begins with a period.

if you've been using any version of linux for more than 7 days, you
should have an understanding, I can tell you're new to linux, or have
been a ubuntu or fedora user for however long... more likely ther latter
given your facination with using RH style structures

Post by Sam
So Red Hat is a somewhat misplaced target of your scorn, this wasn't a
Red Hat thing, at all. They merely strived to remain compatible until
something better came along (supposedly, but that's an argument for some
other time, and place).

Maybe its because I've just got back from holidays and are still in that
mode, but I honestly cant be fucked enough to research it, I know RH used
it decades ago so I align it with it.
By all mewans you keep your wanking over using the rc dot firs rather
than what most of us do, it is after all your system you play with.

[noel]

Post by noel
Maybe its because I've just got back from holidays and are still in that
mode, but I honestly cant be fucked enough to research it, I know RH
used it decades ago so I align it with it.
By all mewans you keep your wanking over using the rc dot firs rather
than what most of us do, it is after all your system you play with.

Well Sam.... whilst I was away I see I had an email from a regular here
I've known for a long time, they inform me of who you are, and if true,
you have been around for a good couple of decades yourself, in fact, back
in the ice age when we used qmail/vpopmail, we used your software (again
if the lurkers info is accurate), but then we got fed up patching qmail
to the point we ended up having sendmail protect it, and i had enough of
that after a while and ordered we move to postfix/dovecot and IIRC you
didn't support IMAP back then so we had to change software, so you have
been around long enough to know not every system uses those dirs or that
slackware has ever used them, of course I cant remember what distro you
coded on, likely a RH variant due to the age, or perhaps debian, but back
then not its african sounding offspring that didn't exist.

[Sylvain Robitaille]

... one wants to have some kind of a reproducible, and automated
process. That is, one that's initiated by a simple, basic command.
Manually editing rc.M is not going to fit the bill.

If you're very good at documenting what changes you make, AND
sufficiently disciplined to always document your changes, manually
editting files works fine. I've been doing that for well over two
decades now. Some tasks get streamlined into more efficient ways of
working, while others still just get editted in.

[Henrik Carlqvist]

Post by Sylvain Robitaille

... one wants to have some kind of a reproducible, and automated
process. That is, one that's initiated by a simple, basic command.
Manually editing rc.M is not going to fit the bill.

If you're very good at documenting what changes you make, AND
sufficiently disciplined to always document your changes, manually
editting files works fine. I've been doing that for well over two
decades now. Some tasks get streamlined into more efficient ways of
working, while others still just get editted in.

Creating a custom Slackware package with some configuration settings
(like a customized startup script) is a good way to document your custom
changes. There are of course also other ways like keeping notes on paper
och copying those customized files to a separate directory for each
macine.

Custom Slackware packages are great if you intend to apply the same
customizations to multiple machines.

regards Henrik

[Sylvain Robitaille]

Post by Henrik Carlqvist
Creating a custom Slackware package with some configuration settings
(like a customized startup script) is a good way to document your
custom changes.

I've contemplated that over the years, but just never quite got to the
point where I felt it was worth the extra steps.

Post by Henrik Carlqvist
There are of course also other ways like keeping notes on paper
och copying those customized files to a separate directory for each
macine.

diff is your friend. Each machine has its own documentation, locally,
so if I want to recreate a change, it's just a matter of looking in the
right spot. Rebuilding from scratch, of course, involves restoring the
documentation from backup, but that's usually easy enough.

Post by Henrik Carlqvist
Custom Slackware packages are great if you intend to apply the same
customizations to multiple machines.

It would, but when you get above a certain (perhaps even "small")
number of machines with the same changes, something like cfengine
becomes more manageable, and serves (in some warped way) as its own
documentation as well. ... but yes, a custom Slackware package would
(also?) be an intelligent way to handle that ...

[Sylvain Robitaille]

Post by noel

Post by Sam
S50mystuff

When I see this I automatically see a redhat or debian user

For what it's worth, or a Solaris sysadmin, or any number of other
System-V based Unix systems admin. None of what we're discussing ever
was unique to Linux. It wasn't misguided advice, by any stretch of
the imagination, even if it isn't "stock" Slackware. It'll work.

[Marco Moock]

Post by Henrik Carlqvist
The script rc.local is being called during the boot process when
going multiuser which happens in runlevel 2,3,4 and 5.

Thanks.
This should be fine.

[Sylvain Robitaille]

Post by Marco Moock
I am looking for the documentation where the sysvinit system of
Slackware is described.

Though somewhat dated, by Slackware-15.0 and Slackware-current
standards, the explanation in the AOLS FAQ document (see
periodically posted pointer in this newsgroup) is still correct.
The newer Slackware versions make (much?) more extensive use of
individual, per-service start/stop scripts than was true when that
explanation was written, but the basic mechanism remains.

Post by Marco Moock
My case is that I have a script to start, stop etc. nscd and I want to
start that together with the other stuff at the right time (which
runlevel is reasonable?).

You probably want this started with run-level 3 (and by extension,
run-level 4). Basically, you need to be in a multi-user mode, with
networking enabled, or else NIS and the like simply aren't going to be
applicable.

Post by Marco Moock
I've searched docs.slackware.com, but I can't find an article about
SysVinit there.

I hope that in addition to other responses you've gotten, the above is
helpful.