Init Process

System V Init

-a distro implementing SysV scheme can be in one of many distinct states in which a predetermined number of processes may be running. These states are called runlevels and to get to a certain runlevel means that the system is in a certain operational stage. -The meaning for each runlevel may vary based on your distribution of Linux. For example, there are a few distributions (such as Ubuntu) that use runlevel 2 to mean multi-user graphical mode with networking enabled -problem: not designed to handle e.g. USBs, external storage volumes, bluetooth devices, the cloud

show -p

(flag) E.g.: systemctl show sshd.service -p Conflicts -to display a single property

--reverse

(flag, like type/state) -to show reverse dependencies (units that depend on the specified unit)

--before --after

(flags) -to show units that depend on the specified unit starting before and after themselves

systemd init (daemon)

-*** as the last step of boot procedure, Linux starts the systemd init daemon as PID (process identifier) # 1. This is the first actual process to run after booting and is the parent of all system processes

rc scripts

-SysVinit daemon is driven by init scripts (aka rc-run command). These are shell scripts located in /etc/rc.d/init.d (symbolic link at /etc/init.d points to /etc/rc.d/init.d -'/etc/rc.d/rcn.d' where n = runlevel the system is entering -/etc/rc.d... directories contain scripts whose names begin with K (kill-executed with stop) and S (start- executed with start). These can be rearranged

service unit

-a daemon (service) that systemd controls

telinit (utility)

-allows a user working with root privileges to bring the system down, reboot the system or change b/w runlevels -a transitional tool; provides compatibility with SysVinit and calls systemctl E.g.: telinit runlevel (where runlevel is one of the runlevels: 0, 1/S, 2, 3, 4, etc.)

journalctl (utility)

-allows you to view and manage the systemd logging subsystem called journald

target

-analogous to a runlevel in previous schemes and is composed of several units. systemd will execute units to reach a target -The instructions for each unit reside in the /lib/systemd/system/ directory

booting the system to single-user/rescue mode

-boot from hard disk, and give GRUB instructions -first display GRUB menu and boot normally; (if you hold SPACE as the system is booting, GRUB displays its menu and stops boot) -unless GRUB setup is modified, you will 1-highlight the kernel you want to boot 2-press 'e' to edit, 3-use down arrow key to move as far down and then use up arrow two lines up (the line begins with eight SPACEs followed by 'linux', 4-use right arrow key until it is past the first argument after 'linux', right before 'root='. Enter SPACE 'single' SPACE and press ctrl-X to boot using the modified kernel 5-enter root password; Linux will display a shell root prompt -then it is running in rescue.target (single-user) mode.

systemctl enable

-causes a daemon to start when system is booted (no effect on current state) E.g.: # systemctl enable atd.service

systemctl disable

-causes daemon no to start when system is booted (no effect on current state) E.g.: # systemctl disable atd.service

systemctl is-enabled

-checks if the unit is enabled

systemctl (utility command) $ systemctl [utility] [application].service

-controls the current and persistent states of daemons that run natively under systemd

system-config-services (utility)

-displays Service Configuration window

to remove additions made

-either delete the unit's '.d' configuration directory OR the modified service file from /etc/systemd/system E.g: snippet: rm -r /etc/systemd/system/nginx.service.d full: rm /etc/systemd/system/ngnix.service

systemd

-goal: to execute only that which is absolutely necessary to get the system to a running state, and you run as much as possible at the same time -to accomplish these goals, systemd aims to act against two major trouble spots of previous init schemes: the shell and parallelism -these ideas have been used in the launchd init scheme for OS X -introduces concepts: units AND targets -Linux daemon names frequently end in 'd' -systemd renames itself 'init' after boot time. 'Init' is a link to systemd

systemctl reload-or-restart

-if unsure whether app can perform reload

systemctl start

-immediately starts a daemon (no effect on booted state)

systemctl stop

-immediately stops a daemon from running (no effect on state on boot) E.g: # systemctl stop atd.service

init

-initializer -a startup manager AND session manager (or system and service manager) for Linux and other UNIXes -startup: it creates/initializes userspace and all ultimately userspace processes -session: takes care of many aspects of userspace and its processes once system is running -2 of the most important init schemes: rc scheme (in 4.4 BSD) AND SysV (SunOS/Solaris)

mountall (Upstart)

-job that mounts all filesystems and triggers various other events (e.g. the 'rc-sysinit' job) related to disk/filesystem initialization

setting the persistent runlevel

-no true runlevels exist under systemd (e.g. default runlevel under Fedora: 'graphical.target' w/alternate name 'runlevel5.target') -Under SysVinit this runlevel is referred to as runlevel 5 -the '/etc/systemd/system/default.target' file is a link to the file that specifies the target the system will boot to by default -'multi-user.target file (and the link to it, 'runlevel3.target) causes the system to boot to the multiuser runlevel (SysVinit runlevel 3)

service AND chkconfig (utilitiy commands)

-originally controlled daemons that run under SysVinit, and were upgraded to control daemons that run under Upstart; ***now these utilities have been retrofitted to control daemons that run under systemd, which they do by calling systemctl -'service' (to control current state) and 'chkconfig' (to control persistent state) can still be used

systemctl daemon-reload

-reload the systemd process after deleting a file/directory

systemctl restart

-restarts a running service

rc-sysinit (Upstart)

-role: to bring the system to its default runlevel. It executes the command telinit <runlevel> to achieve this. The telinit command then emits the runlevel event, which causes many other jobs to start

systemctl halt

-shortcut to halt the system

systemctl poweroff

-shortcut to initiate a full shutdown

systemctl reboot

-shortcut to initiate a reboot

systemctl rescue

-shortcut to put the system into rescue (single-user) mode -use this instead of isloate rescue.target

shortcuts

-sometimes can also just be given without the 'systemctl', eg just: $ reboot

target unit

-special type of unit file that glues the other types together into a cohesive whole -*** important: targets that control the system runlevel. systemd init supports target units (not runlevels), which parallel runlevels but are different E.g. For ArchLinux: [Unit] Description=Basic System Documentation=man:systemd.special(7) Requires=sysinit.target Wants=sockets.target timers.target paths.target ↪slices.target After=sysinit.target sockets.target timers.target ↪paths.target slices.target JobTimeoutSec=15min JobTimeoutAction=poweroff-force -The Requires and Wants directives above are how systemd defines the dependency chain among the units. The Requires directive denotes a hard requirement, and Wants denotes an optional requirement. Also keep in mind that Requires and Wants don't imply order. If the After directive isn't specified, systemd will start the units in parallel.

init daemon process

-started by the kernel -first userspace process to spawn and last one to die during shutdown

Upstart init

-superset of SysV init code, providing backward compability -implements an event-driven model that allows it to respond to milestones asynchronously as they are reached. System initialization can be expressed as a consecutive set of "spawn process X when event Y occurs" rules -used with Ubuntu and RHEL6

systemctl isolate

-this command changes the current runlevel of the system -E.g.: # systemctl isolate graphical.target

booting the system

-this is the process of reading the Linux kernel into memory and starting it running

systemctl is-failed

-to check whether the unit is in a failed state-this indicates that there was a problem starting the unit

ps -ef | grep atd

-to determine whether daemon is running

systemctl get-default

-to find the default target for your system

systemctl list-unit-files --type=target

-to get a list of the available targets on your system

systemctl list-unit-files

-to see every available unit file within the systemd paths, including the ones systemd hasn't attempted to load

sysv-rc-conf OR chkconfig (Upstart)

-tools to manage the runlevel of different services. You also can manage jobs via the initctl utility -$ initctl status <job> -$ initctl list -# initctl start|stop <job>

daemons

-two states are important: current state (e.g. running OR stopped)and persistent state (state after system is booted)

apropos (name of systemd function)

-use apropos to list man pages pertaining to systemd (e.g. apropos systemd, systemctl, systemd.unit, and systemd.special)

systemctl reload

-use this if the app in question is able to reload its configuration files without restarting

# journalctl -b -p err

Display errors from last boot

# journalctl --all

Display full log

# journalctl -b

Display log since last boot

systemctl edit OR systemctl edit --full

E.g.: sudo systemctl edit nginx.service -to edit and modify unit files -it will be a blank file that can be used to override or add directives to the unit definition. A directory will be created in /etc/systemd/system directory which contains the name of the unit with '.d' appended (e.g. nginx.service > nginx.service.d) -full flag is to edit the full unit file instead of creating a snippet

isolate

E.g.: sudo systemctl isolate multi-user.target (But first look at the target dependencies: systemctl list-dependencies multi-user.target,) -to start all of the units associated with a target and stop all units that aren't part of the dependency tree (similar to changing runlevel in other init). E.g. if you wanted to change from graphical to multi-user, use the above.

systemctl mask

E.g.: sudo systemctl mask nginx.service -to mask the unit; to mark a unit as completely unstartable, automatically or manually by linking it to /dev/null -if you try starting a masked service (e.g. nginx), it will say: Failed to start nginx.service... masked. -systemctl list-unit-files will show masked files

systemctl unmask

E.g.: sudo systemctl unmask nginx.service -to unmask

systemctl list-dependencies

E.g.: systemctl list-dependencies sshd.service -to see a unit's dependency tree

--all

E.g.: systemctl list-units --all -to see all units that have been loaded (or attempted) regardless of whether they are currently active

--state=

E.g.: systemctl list-units --all --state=inactive -state is used to indicate Load, Active, or Sub states we wish to see. You must keep the --all flag

--type=

E.g.: systemctl list-units --type=service -used to only display units of the type of units we're interested in

set-default

E.g.: systemctl set-default graphical.target (for graphical) -use this to change your default target accordingly

systemctl show

E.g.: systemctl show sshd.service -to see low-level properties of a unit

systemctl cat

E.g: systemctl cat atd.service -to display the unit file that systemd has loaded into its system

# journalctl /lib/systemd/systemd

Filter log by executable

# journalctl -f

Tail the log

systemctl status

shows Active status

systemctl list-units ALSO: systemctl list-units --type=target | egrep 'multi-user|graphical'

-will show a list of all the units that systemd has active -the columns: ..Unit: the systemd unit name ..Load: whether the unit's configuration has been parsed by systemd ..Active: summary state about whether the unit is active -Sub: this is a lower-level state that indicates more detailed information about the unit. This often varies by unit type, state, and the actual method in which the unit runs. -Description: short textual description of what the unit is/does

service

-you can use the 'systemctl status' command to determine whether systemd is controlling a daemon natively or via a SysVinit script -***you can use 'service to display info similar to systemctl status, but service doesn't accept a period and unit type E.g.: $ service cups status $ service network status

systemctl is-active

displays a status