On Fri, 8 Nov 2019 17:51:18 +0100, "R.Wieser" 
declaimed the following:

>
>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 ...
>
 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






>>
https://www.debian.org/doc/manuals/debian-reference/ch03.en.html#_stage_4_the_n
ormal_debian_system
>
>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

 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.

>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)
>
>> (run level 5 maps to the graphical display target)
>
>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") ?
>

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.
"""


>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 ...).
>

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
 wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05