PAM means Pluggable Authentication Module and is based on RFC 86.0.
pam_unix and pam_systemd are two different modules with different roles. According to their respective man pages:
pam_unix [is the m]odule for traditional password authentication
[...]
This is the standard Unix authentication module. It uses standard
calls from the system's libraries to retrieve and set account
information as well as authentication. Usually this is obtained from
the /etc/passwd and the /etc/shadow file as well if shadow is enabled.
and
pam_systemd [r]egister[s] user sessions in the systemd login manager
[...]
pam_systemd registers user sessions with the systemd login manager
systemd-logind.service(8), and hence the systemd control group
hierarchy.
I took a quick look at the source code and the man pages, and I think the simple answer is:
TimeoutStopSec=
Configures the time to wait for stop. If a service is asked to stop, but does not terminate in the specified time, it will be terminated forcibly via SIGTERM, and after another timeout of equal
duration with SIGKILL (see KillMode= in systemd.kill(5)). Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass "0" to disable the timeout logic. Defaults to
DefaultTimeoutStopSec= from the manager configuration file (see systemd-system.conf(5)).
So I look at /etc/systemd/system.conf and find:
#DefaultTimeoutStopSec=90s
So when the systemd reboot target happens systemd gets a Set of pids for children it owns. Looking at the source code, systemd/src/core/killall.c seems to show that:
static int killall(int sig, Set *pids, bool send_sighup)
takes a list of pids for all children of systemd and gets called by:
broadcast_signal(int sig, bool wait_for_exit, bool send_sighup)
Which is in the same file. So I assume any child of pid 1, will eventually get the default signal of SIGTERM, and without a unit file, the optional SIGHUP is probably never sent, it will wait the configured DefaultTimeoutStopSec and then send a SIGKILL.
Best Answer
initis (usually) the first process started by the system. It has a couple of special responsibilities, including (but not limited to:initis what ultimately tells the kernel to power off or reboot once everything in userspace is shut down).A service manager, on the other hand, is solely responsible for ensuring a given set of services are running, and optionally that they keep running. The exact approach to this can vary from rudimentary scripts that just track dependencies among services, to complex systems that automatically manage dependencies.
The original SVR4
initimplementation (which is the basis for both the classicsystemv-initpackages on most Linux distributions, the Busyboxinitapplet, and the BSD and Solarisinitprograms) actually included rudimentary service management. It let you define programs which it would automatically start at boot, and restart if they exited. As a result of this, it's actually pretty hard to find aninitimplementation on a UNIX-like system that isn't also a rudimentary service manager, and this baseline level of service management is largely implied to be part of theinitprocess's job.On the other hand, you can easily have a service manager that isn't an
initimplementation. The classic BSDrc.dscripts are an example of a really simple service manager (they handle starting and stopping services, and provide rudimentary dependency management), and they formed the basis of the concept of/etc/init.don Linux. A more complex example is monit, which adds state tracking, automatic restart capabilities, alerting, and some system monitoring support to the basic functionality.