init.d is there a info and/or a tutorial available ?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello all,

I wanted to add a shell script to init.d, and and had a ball with googeling  
enough info to be able to successfully add a script to the boot sequence.  
:-\

But there is something I've not been able to find: a(n even halfday decent)  
description of, in the header of such a script, what entries are possible  
and what the arguments to them mean.

For instance, there is a "Default-Start:" line followed by a number of  
digits and sometimes an "s" too.   No idea what they mean, or why there are  
multiple present.

Also, I don't get the "Required-Start:" line.    The "bluetooth" script  
mentions "$local-fs" and "$syslog" as requirements, while the "fake-hwclock"  
script mentions neither.   Though both have entries in /var/log/syslog ...

In other words, although I've got /something/ running, I have no idea /why/  
it runs - and if I've not overdone it (in regard to certain arguments).

So, does anyone know of a decent description of that init.d files header ?  
Possibly an example/template file too ? :-)

Regards,
Rudy Wieser



Re: init.d is there a info and/or a tutorial available ?
On Fri, 08 Nov 2019 11:29:09 +0100, R.Wieser wrote:
Quoted text here. Click to load it

What version of what distro you're using might matter. But...

man chkconfig

If you're not using chkconfig or the like, just plunk the
script into the proper rc.[012345] directory and leave out/ignore
all those structured comments.

Web search "BEGIN INIT INFO" comes up with useful things like:

https://refspecs.linuxfoundation.org/LSB_1.2.0/gLSB/initscrcomconv.html
http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/
initscrcomconv.html
https://www.thegeekstuff.com/2012/03/lsbinit-script/

Re: init.d is there a info and/or a tutorial available ?
Joe,

Its the raspbian version that comes with noobs v3.2.0.  Not sure which  
version it is.  No idea how to check that.

Quoted text here. Click to load it

No manual entry for that available.

Quoted text here. Click to load it

I have /no/ idea what would be proper or impoper about those folders.  For  
that I would need to have some more information about their purposes ...  
<whistle>

Quoted text here. Click to load it

Grumble ...   I should have thought of that.

Quoted text here. Click to load it

Allo of those stop exactly where my question starts: What is a  
"boot_facility_" or "run_level_" ?   Which one(s) should my script have, and  
most importantly, why ?

Before posting here I also found the below one, but it suffers from the same  
problem as the ones you found:
https://wiki.debian.org/LSBInitScripts

Regards,
Rudy Wieser



Re: init.d is there a info and/or a tutorial available ?
On 8.11.19 16:55, R.Wieser wrote:
Quoted text here. Click to load it

Open the console and type the commands

uname -a
cat /etc/issue

and tell waht the machine responds.

--  

-TV

Re: init.d is there a info and/or a tutorial available ?
Tauno,

Quoted text here. Click to load it

4.19.57-v7+

Quoted text here. Click to load it

Raspbian GNU/Linux 10

By the way: Why both ?  What does the first tell you that the second doesn't  
(or vise-verse) ?

Regards,
Rudy Wieser



Re: init.d is there a info and/or a tutorial available ?
On 08/11/2019 17:32, R.Wieser wrote:
Quoted text here. Click to load it

They are completely different and unrelated things. uname -a tells you  
the kernel version, /etc/issue tells you the name of the distro release.

---druck

Re: init.d is there a info and/or a tutorial available ?
declaimed the following:

Quoted text here. Click to load it

    Sys-V init.d is, to my knowledge, being deprecated in Debian based
systems. It is being replaced with systemd (and even more cryptic scheme,
in my mind) -- though the link (below) implies some of it is still in use.

Quoted text here. Click to load it


    The common init.d scheme is to have one directory with a pair of files
for each feature. The file will have an S or K (start/kill), some name with
a few digits to provide a priority..

    Then, in the various run-level directories, there will be sym-links to
the real files. When an init.d system changes run-level, it runs the k*
files for the current level, then runs the s* files for the level it is
transitioning into..

https://wiki.debian.org/RunLevel
https://www.debian.org/doc/manuals/debian-reference/ch03.en.html#_stage_4_the_normal_debian_system
"""
systemd offers backward compatibility features. SysV-style boot scripts in
"/etc/init.d/rc[0123456S].d/[KS]<name>" are still parsed and telinit(8) is
translated into systemd unit activation requests.
"""
    Further down it mentions that Sys-V run levels 2-4 all result in the
same systemd "target" (run level 5 maps to the graphical display target)


--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: init.d is there a info and/or a tutorial available ?
Dennis,

Quoted text here. Click to load it

I have not found anything even mentioning that scheme.  Just ones which talk  
about putting a single script into the init.d folder (and calling  
update-rc.d when done).

Quoted text here. Click to load it

Thanks, though it just very slightly lifts a slip of the veil I'm afraid.  
What do runlevels 2...5 signify ?   Which one(s) should I use, and why ?  
And (why) should I bother with level 1 (single user) ?   AFAIK thats a  
rather special mode to boot in ...

Quoted text here. Click to load it

I'm sorry, but at this moment I'm not going to spend energy at trying to  
figure out sys-v, only to than have to break my head about which parts of  
that are valid for init.d and which parts definitily not.   Thats a  
multilayer puzzle I do not yet have the knowledge for I'm afraid (the terse  
remarks on the above webpage related to init.d are definitily not enough for  
me)

Quoted text here. Click to load it

Wait, what ?    Is that number not one of the multi user modes ?     Or is  
something like "the graphical display target" a user too ?

Also, I mentioned an "S" as a "Default-Start:"  argument.  What is that one  
supposed to mean ?    Also, why would a single-user run-level be part of the  
"Default-Stop:" line (see "/etc/init.d/fake-hwclock") ?

Yes, thats the level of "detail" (not detail at all as far as I'm concerned)  
I'm looking for I'm afraid (very odd that googeling for "init.d" does not  
pop up such info every second or third result if you ask me ...).

Regards,
Rudy Wieser



Re: init.d is there a info and/or a tutorial available ?
declaimed the following:

Quoted text here. Click to load it
    Run level 1 is basically the equivalent of Window "safe mode" -- it is
a console only mode that originally (and maybe still) used the system
serial port, no network SSH/telnet logins. Remember init.d comes from
System V UNIX, from a time before "single user computers". Level 5
traditional runs an X-Server* on the machine itself, connected to a
graphical display.

    Levels 2-4 were available to allow site admins to define intermediate
states. Perhaps level 2 would be set up to allow multiple logins only via
hardware serial ports, but with no networking. Level 3 might be hardware
serial but with networking enabled but no network login. Level 4 might
allow logins over the network (SSH or, back then, TELNET).

    As the second link states -- the current systemd control treats levels
2-4 as a single non-graphical multi-user target.

https://www.2daygeek.com/sysvinit-vs-systemd-cheatsheet-systemctl-command-usage/
Heh... My above hypothesis was close (my level 4 is the common level 3).
This site has:  
Short Description     SysVinit Command     systemd Command

Single user mode     1, S, single     runlevel1.target, rescue.target
Multi User     2     runlevel2.target, multi-user.target
Multi User with Network     3     runlevel3.target, multi-user.target
Experimental (No User)     4     runlevel4.target, multi-user.target
Multi-user with Graphical & Network     5     runlevel5.target,
graphical.target






Quoted text here. Click to load it

    Sys-V init IS init.d. systemd processes it as an interim for upgrading
systems rather than force admins to convert all their localized start-up to
systemd service files.

Quoted text here. Click to load it

pi@rpi3bplus-1:~$ cat /etc/init.d/fake-hwclock
#!/bin/sh

### BEGIN INIT INFO
# Provides:          fake-hwclock
# Required-Start:
# Required-Stop:     umountroot
# Should-Stop:
# X-Start-Before:    checkroot
# Default-Start:     S
# Default-Stop:      0 1 6
# Short-Description: Restore / save the current clock
# Description:
### END INIT INFO


    *** the above are all comments. Run level "S" likely means "on start-up
-- before transitioning to actual end run level". If you look in /etc/rcS.d
you will find an S01fake-hwclock, and /etc/rc0.d (1.d, 6.d) you find
K01fake-hwclock. These are sym-links to the above file. When /entering/
run-level S, S01fake-hwclock will be invoked with the "start" parameter.
When entering run-level 0, 1, or 6, K01fake-hwclock will be invoked with
the "stop" parameter.

    ALL scripts in /etc/init.d/* are only executed if: 1) an admin manually
invokes (service xyz start, service xyz stop), or they are sym-linked in
one or more of the rc#.d directories (where the prefix tells if kill or
start, and what priority it should be). I suspect the above comment block
is used by update-rc.d program to populate the symlinks...

From man update-rc.d
"""
INSTALLING INIT SCRIPT LINKS
       update-rc.d requires dependency and runlevel information to be
provided in the  init.d
       script  LSB  comment header of all init.d scripts.  See the
insserv(8) manual page for
       details about the LSB header format.

       When  run  with  the  defaults  option,  update-rc.d  makes  links
named  /etc/rcrun-
       level.d/[SK]NNname  that  point to the script /etc/init.d/name,
using runlevel and de-
       pendency information from the init.d script LSB comment header.
"""


Quoted text here. Click to load it

https://www.tldp.org/HOWTO/HighQuality-Apps-HOWTO/boot.html (see 9.3)

pi@rpi3bplus-1:~$ ls  /etc/rc*.d
/etc/rc0.d:
K01alsa-utils    K01dhcpcd        K01hwclock.sh  K01nfs-common  K01plymouth
K01rsyslog
K01avahi-daemon  K01fake-hwclock  K01lightdm     K01nginx K01rng-tools
K01triggerhappy
K01bluetooth     K01fcgiwrap      K01networking  K01paxctld     K01rpcbind
K01udev

    When entering level 0 (power-off/shutdown), stops all the above
services

/etc/rc1.d:
K01alsa-utils    K01dhcpcd        K01lightdm     K01paxctld    K01rsyslog
K01avahi-daemon  K01fake-hwclock  K01nfs-common  K01rng-tools
K01triggerhappy
K01bluetooth     K01fcgiwrap      K01nginx       K01rpcbind

    When entering level 1, stops the above

/etc/rc2.d:
S01avahi-daemon      S01dbus            S01lightdm   S01raspi-config S01ssh
S01bluetooth         S01dhcpcd          S01nginx     S01rng-tools S01sudo
S01console-setup.sh  S01dphys-swapfile  S01paxctld   S01rsync
S01triggerhappy
S01cron              S01fcgiwrap        S01plymouth  S01rsyslog

/etc/rc3.d:
S01avahi-daemon      S01dbus            S01lightdm   S01raspi-config S01ssh
S01bluetooth         S01dhcpcd          S01nginx     S01rng-tools S01sudo
S01console-setup.sh  S01dphys-swapfile  S01paxctld   S01rsync
S01triggerhappy
S01cron              S01fcgiwrap        S01plymouth  S01rsyslog

/etc/rc4.d:
S01avahi-daemon      S01dbus            S01lightdm   S01raspi-config S01ssh
S01bluetooth         S01dhcpcd          S01nginx     S01rng-tools S01sudo
S01console-setup.sh  S01dphys-swapfile  S01paxctld   S01rsync
S01triggerhappy
S01cron              S01fcgiwrap        S01plymouth  S01rsyslog

    Levels 2, 3, and 4 all start the same set of services

/etc/rc5.d:
S01avahi-daemon      S01dbus            S01lightdm   S01raspi-config S01ssh
S01bluetooth         S01dhcpcd          S01nginx     S01rng-tools S01sudo
S01console-setup.sh  S01dphys-swapfile  S01paxctld   S01rsync
S01triggerhappy
S01cron              S01fcgiwrap        S01plymouth  S01rsyslog

    As does level 5

/etc/rc6.d:
K01alsa-utils    K01dhcpcd        K01hwclock.sh  K01nfs-common  K01plymouth
K01rsyslog
K01avahi-daemon  K01fake-hwclock  K01lightdm     K01nginx K01rng-tools
K01triggerhappy
K01bluetooth     K01fcgiwrap      K01networking  K01paxctld     K01rpcbind
K01udev

    Level 6 (reboot) kills everything

/etc/rcS.d:
K01hwclock.sh  S01alsa-utils    S01keyboard-setup.sh  S01plymouth-log
S01udev
K01nfs-common  S01apparmor      S01kmod               S01procps
S01x11-common
K01rpcbind     S01fake-hwclock  S01networking         S01raspi-config
pi@rpi3bplus-1:~$

    Startup stops hwclock, nfs-common, and rpcbind; starts alsa-utils, and
some other items.

    I suspect one doesn't see the X-server in level 5 because systemd is
uing the graphical.target entry

pi@rpi3bplus-1:~$ cat /lib/systemd/system/graphical.target
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target
display-manager.service
AllowIsolate=yes
pi@rpi3bplus-1:~$


* X-servers are the hardware that renders the display, X-clients are
programs that send display requests to the X-server. So -- sort of
backwards from how most client/server systems are viewed -- you are sitting
at the server and starting client programs on the remote mainframe, instead
of running clients at your end that ask for stuff on a remote server
maching. For a short period of time, the idea was that the mainframe would
run X-clients (which might be just applications or could include a whole
"desktop" environment) which routed display updates via network to X-window
terminals (which were basically very dumb computers that only ran the
X-server software and network protocols).

From a terminal in the graphical desktop:
pi@rpi3bplus-1:~$ echo $DISPLAY
:0.0
pi@rpi3bplus-1:~$  

From a SSH terminal connected to the very same device:
pi@rpi3bplus-1:~$ echo $DISPLAY

pi@rpi3bplus-1:~$

    When using a X-server terminal, and connecting to a remote computer,
one normally had to define the DISPLAY environment variable with the
specification of the user's terminal device (network ID, display number,
etc.) The SSH session has on defined graphical display.



--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: init.d is there a info and/or a tutorial available ?
Dennis,

Quoted text here. Click to load it

Thats what I remembered, hence the "very special mode".

Quoted text here. Click to load it

:-) Thats not something I could have remembered I'm afraid.

Quoted text here. Click to load it

Thanks.  It at least has a bit more descriptive names for those runlevels.  
Still feel I have to guess a lot about what they are for though - Still have  
no idea when to use those runlevels, or why (I'm a freshling, with  
little-to-no knowledge about Linux or its history).

Ah, it seems that "S" and "1" (and "Single") are the same.  One thing less  
to "worry" about.

Quoted text here. Click to load it

Yeah, I totally knew that ofcourse. :p

Quoted text here. Click to load it

Is that "upgrading" ment as in the boot process, or should I take that as  
meaning that raspbian itself is considered an in-between step to something  
else ?

Quoted text here. Click to load it

In short, when entering run-level 1 it will get started *and* stopped.  
Which could make sense in fake-hwclock's case.

Quoted text here. Click to load it

Currently I assume the same.   Makes me wonder why the source script needs  
to be placed in the init.d folder though ...

Quoted text here. Click to load it

Grumble ...   I tried "man init.d" and got nothing.  Didn't think to do the  
same for update-rc.d though. :-\

Quoted text here. Click to load it

Bingo!   Or maybe not: "man insserv" -> "No manual entry for insserv" ?

Quoted text here. Click to load it

Hmmm ...  Chapter "9.2. Runlevels" shows a bit more detailed info about  
those run-level numbers - and when they are supposed to be used. :-)

Quoted text here. Click to load it

I think I should put a script specifying all the runlevels into system.d,  
and see if I can syslog the crap outof it (assuming/hoping the run-level is  
mentioned in the arguments).

Quoted text here. Click to load it

That doesn't sound to odd to me to be honest, just a case of which  
POV/perspective you (wish to) have.   I could argue that when I can execute  
programs (on the mainframe) that I can leave and reconnect to at will than  
I'm the controller, and they are the childs (even if I'm doing it on a dumb  
terminal, with my actual OS also on the mainframe).

Thanks again.   Some of the info still goes a bit over my head, but overall  
my "picture sharpness" improves. :-)

Regards,
Rudy Wieser



Re: init.d is there a info and/or a tutorial available ?
On Sat, 9 Nov 2019 10:11:46 +0100

Quoted text here. Click to load it

    For a little historical perspective -before SYSV init there
was /etc/rc and /etc/rc.local - two shell scripts one for the system the
other for the sysadmin. The latter may have been an addition.

    This approach was not conducive to automatic maintenance and so SYSV
init was created as a somewhat over-engineered solution. Over-engineering
was popular in the SYSV camp at the time - another great example was
streams, the SYSV networking stack it was ingenious and incredibly flexible
but sockets were simpler and better matched to the requirements.

    IME nobody ever found real use for more than two run levels
(maintenance and normal operation) hence BSD init which essentially just
adds a directory and some conventions for scripts to manage services to the
original mechanism.

--  
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.
Re: init.d is there a info and/or a tutorial available ?
declaimed the following:

Quoted text here. Click to load it

    It's between using Sys-V init.d only and using systemd only... And I
should note that there is a systemd descriptor file that invokes
fake-hwclock, so even the init.d variant may not be used...

    And different web pages have different takes on S level -- being either
start-up (before getting to a user run-level) or equivalent to level 1...

    Level 2-4 can be ignored since all three are considered systemd
multiuser.target, 5 is graphical.target (which requires multiuser.target).

Quoted text here. Click to load it

    Under init.d, possibly... but under systemd those run-level scripts are
only processed if invoked by the systemd setups -- and systemd doesn't
appear to enter run level 1 before going to run level 5. Using the command
to display previous/current run level showed
N 5
(No run level) (direct to level 5/graphical).

    Here's the systemd fake-hwclock service description...

pi@rpi3bplus-1:~$ cat /lib/systemd/system/fake-hwclock.service
[Unit]
Description=Restore / save the current clock
Documentation=man:fake-hwclock(8)
DefaultDependencies=no
Before=sysinit.target systemd-fsck-root.service
Conflicts=shutdown.target

[Service]
EnvironmentFile=-/etc/default/fake-hwclock
ExecStart=/sbin/fake-hwclock load $FORCE
ExecStop=/sbin/fake-hwclock save
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target
pi@rpi3bplus-1:~$


    Note the "Before=sysinit.target" line. This indicates that this service
has to run before the rest of sysinit, and even before the boot-up
systemd-fsck-root check (in order to give the system a time stamp that is
close to the time stamp of the root file system). I suspect the "Conflicts"
line is what sets this to run the stop action if systemd is activating the
shutdown.target.



Quoted text here. Click to load it

    Nothing? I get "No manual entry for init.d"... But yeah... Sys-V init
is so low-level it has no useful runtime information. The closest is
probably

pi@rpi3bplus-1:~$ apropos init.d
git-init-db (1)      - Creates an empty Git repository
init-d-script (5)    - interpreter for short and simple init.d scripts.
initrd (4)           - boot loader initialized RAM disk

pi@rpi3bplus-1:~$ man init-d-script

NAME
       init-d-script - interpreter for short and simple init.d scripts.

DESCRIPTION
       Generic  init.d  script  framework  to reduce the redundant code in
/etc/init.d/.  The
       goal is to create an init.d script that is Debian and LSB compliant.
When the  Debian
       policy conflict with the LSB, the Debian policy take preference. See
The LSB specifi-
       cation
?http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-
       generic/iniscrptact.html? for information about init.d scripts in
the LSB.

       This  is  a simple example on how init-d-script can be used to start
and stop a daemon
       with PID file support:

       #!/usr/bin/env /lib/init/init-d-script
       ### BEGIN INIT INFO
       # Provides:          atd
       # Required-Start:    $syslog $time $remote_fs
       # Required-Stop:     $syslog $time $remote_fs
       # Default-Start:     2 3 4 5
       # Default-Stop:      0 1 6
       # Short-Description: run at jobs
       # Description:       Debian init script to start the daemon
       #                    running at jobs.
       ### END INIT INFO
       DAEMON=/usr/sbin/atd

(Of course, there are more pages of stuff)


Quoted text here. Click to load it

    Debian tends to override pure LSB, with the result that stuff aimed at
LSB tends to not be present (not even as a package to be installed) -- one
reason I tend to hit Google first.



--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: init.d is there a info and/or a tutorial available ?
Don't bother, Raspbian now uses systemd.

Site Timeline