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 ? :-)
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:
Its the raspbian version that comes with noobs v3.2.0. Not sure which version it is. No idea how to check that.
No manual entry for that available.
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 ...
Grumble ... I should have thought of that.
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:
On Fri, 8 Nov 2019 11:29:09 +0100, "R.Wieser" declaimed the following:
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.
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..
formatting link
formatting link
""" systemd offers backward compatibility features. SysV-style boot scripts in "/etc/init.d/rc[0123456S].d/[KS]" 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
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
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).
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 ...
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)
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 ...).
On Fri, 8 Nov 2019 17:51:18 +0100, "R.Wieser" declaimed the following:
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.
formatting link
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
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.
### 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. """
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.
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
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Thats what I remembered, hence the "very special mode".
:-) Thats not something I could have remembered I'm afraid.
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.
Yeah, I totally knew that ofcourse. :p
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 ?
In short, when entering run-level 1 it will get started *and* stopped. Which could make sense in fake-hwclock's case.
Currently I assume the same. Makes me wonder why the source script needs to be placed in the init.d folder though ...
Grumble ... I tried "man init.d" and got nothing. Didn't think to do the same for update-rc.d though. :-\
Bingo! Or maybe not: "man insserv" -> "No manual entry for insserv" ?
Hmmm ... Chapter "9.2. Runlevels" shows a bit more detailed info about those run-level numbers - and when they are supposed to be used. :-)
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).
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. :-)
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
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
On Sat, 9 Nov 2019 10:11:46 +0100, "R.Wieser" declaimed the following:
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).
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
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.
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 ?
formatting link
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)
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
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.