Am Sa., 4. Jan. 2020 um 00:16 Uhr schrieb Russ Allbery <r...@debian.org>:
>
> The Wanderer <wande...@fastmail.fm> writes:
>
> > What I'm concerned about is dbus socket activation, or similar, leading
> > to e.g. logind getting activated by logging in at the text console.
>
> > I thought I understood that socket activation via dbus was one of the
> > features which didn't require systemd as PID-1 to function.
>
> It may be that the user service manager in systemd supports D-Bus socket
> activation, but none of the user services provided in the systemd package
> seem to start logind, so I don't think you'll get that service started
> that way. I'm only seeing systemd-exit and systemd-tmpfiles.
>
> Also, I'm not sure what would start the user service manager if you're not
> running systemd as PID 1.
Indeed. Looking through the large set of binaries and interfaces
provided by the systemd package, I do wonder though: One of the points
of the systemd project is to actually provide interfaces applications
and the OS can rely on being present. For that matter, it simply
doesn't make sense to split up the systemd package, as it makes
maintenance harder and may only introduce issues. At the same time
though, the usecase of containers and minimal chroots exists, where
you sometimes want to save as much space as possible and where you
will never ever run a full initsystem / service manager.
The systemd maintainers already split out machinectl and nspawn into
their own systemd-container package, as it's not needed in every
configuration.
Potentially, splitting out the bare minimum binaries to run a Debian
system in a container setting / minimal chroot makes sense for the
Debian systemd maintainers. This, coincidentally, would also put users
of other init systems at ease. I believe by approaching the problem
that way, there may actually be a possibility for mutually beneficial
synergies here.
Looking through the postinst scripts and contents of the systemd
package, I am very certain that it won't suddenly run anything if
you're not already on a systemd-as-PID1 system. So having it should be
safe for alternative initsystems (however, note that I haven't tested
that).
The systemd package currently (244-3) contains the following utilities[1]:
## (mostly) User-invoked CLI tools
Those are components usually invoked by a human, but may be used in
scripts as well.
* journalctl: Read the system journal, if available (otherwise does nothing)
* loginctl: Control login sessions, logind related stuff
* systemctl: Control system services / system state
* systemd-escape: Escape strings for usage in systemd unit names
* systemd-inhibit: Execute a program with an inhibition lock taken
(e.g. prevent sleep/idle)
* bootctl: Control the firmware and boot manager settings
* busctl: Introspect the bus (D-Bus)
* hostnamectl: Control system hostname and related stuff
* kernel-install: Add and remove kernel and initramfs images to and from /boot
* localectl: Change system locale
* timedatectl: Modify system time/date
* resolvectl: Introspect and reconfigure the DNS resolver
* systemd-analyze: Analyze and debug system manager (only useful if
systemd is PID1)
* systemd-cat: Connect a pipeline or program's output with the journal
* systemd-cgls: Recursively show control group contents
* systemd-cgtop: Show top control groups by their resource usage
* systemd-delta: Find overridden configuration files
* systemd-id128: Generate and print sd-128 identifiers
* systemd-mount, systemd-umount: Establish and destroy transient
mount or auto-mount points
* systemd-path: List and query system and user paths
* systemd-run: Run programs in transient scope units, service units,
or path-, socket-, or timer-triggered service units (needs the service
manager to be PID1)
* systemd-socket-activate: Test socket activation of daemons
## Systemd core components
These components are usually invoked by scripts, but may be used by
humans as well.
* systemd: PID1
* systemd-ask-password: Query for a root password, e.g. when a
bootsplash is active. Possibly useful w/o sd PID1
* systemd-machine-id-setup - Initialize the machine ID in /etc/machine-id
* systemd-notify: Notify service manager about start-up completion
and other daemon status changes
* systemd-sysusers: Allocate system users and groups
* systemd-tmpfiles: Creates, deletes and cleans up volatile and
temporary files and directories
* systemd-tty-ask-password-agent: List or process pending systemd
password requests
* systemd-detect-virt: Detect execution in a virtualized environment
* systemd-stdio-bridge: STDIO or socket-activatable proxy to a given
DBus endpoint.
## Daemons
Some of them are enabled by default, some of them are optional and
have to be activated by the users, some of them (like journald) run in
modes which actually only forward data to other preexisting services
by default (rsyslog) unless instructed otherwise by the user.
None of those are run on systemd where systemd isn't PID1, because all
of them only have a service file.
* timesyncd: Network Time Synchronization
* logind: Login manager
* networkd: Network manager (does nothing unless configured)
* systemd-pstore: Tool to archive contents of the persistent storage filesytem
* resolved: Network Name Resolution manager
* systemd-sleep: System sleep state logic
## Generators
Generators are part of the service manager and are run by
systemd-as-PID1 to create temporary service units from other files, or
set up other state at early boot.
This is what creates sysvinit compatibility for systemd nowadays.
Here's just a list of them, they aren't supposed to be run by users
and do nothing if not invoked.
* systemd-bless-boot-generator
* systemd-cryptsetup-generator
* systemd-debug-generator
* systemd-fstab-generator
* systemd-getty-generator
* systemd-gpt-auto-generator
* systemd-hibernate-resume-generator
* systemd-rc-local-generator
* systemd-run-generator
* systemd-system-update-generator
* systemd-sysv-generator
* systemd-veritysetup-generator
## Private Library
* libsystemd-shared: C helper functions shared by all systemd binaries
## System configuration
* /lib/modprobe.d/systemd.conf: Disables bond0 creation
## Systemd service units to start daemons / oneshot services / timers etc.
Lots of service units used by the systemd service manager. Do nothing
if that isn't used and nothing parses the .service units. Those run
various tasks to manage the system, please look at them individually
to see what they do.
## (D-Bus) Interfaces
Some API for applications to change system parameters. Logind may also
fall into this category, but that has already been mentioned.
* hostnamed: D-Bus interface to change the host name
* localed: Locale bus mechanism (change system locale)
* timedated: Time and date bus mechanism
## Systemd helper executables
Lots and lots of binaries (44) in /lib/systemd/. Some of them are
daemons run by the service units, some of them are helpers for certain
simple tasks that intregrate with the other services. Here's a list of
some that weren't explicitly or implicitly mentioned already:
* systemd-ac-power
* systemd-backlight
* systemd-binfmt
* systemd-cgroups-agent
* systemd-cryptsetup
* systemd-dissect
* systemd-fsck
* systemd-growfs
* systemd-hibernate-resume
* systemd-initctl
* systemd-makefs
* systemd-modules-load
* systemd-quotacheck
* systemd-random-seed
* systemd-remount-fs
* systemd-reply-password
* systemd-rfkill
* systemd-shutdown
* systemd-socket-proxyd
* systemd-sulogin-shell
* systemd-sysctl
* systemd-time-wait-sync
* systemd-timesyncd
* systemd-update-utmp
* systemd-user-runtime-dir
* systemd-user-sessions
* systemd-veritysetup
* systemd-volatile-root
## UDev rules
Some udev rules that may be useful for every system.
## Sysctl config
Bumps the numeric PID range to its maximum of 2^22
## Systemd boot misc files
They do nothing, but are there if someone wants to use sd-boot
## Manual pages
## Localization
## Bash and Zsh completion
I do hope this clears up some of the questions. A lot of stuff in the
systemd package isn't useful at all on systems where systemd isn't
PID1, but it also should be pretty much completely inert there. On the
other hand, quite a few of these components may actually be useful
everywhere, localed, resolved, timedated, sysusers, tmpfiles,
detect-virt, etc. all AFAIR don't need systemd to be PID1 and could
possibly be really useful if users of other initsystems decide to wire
them up.
Overall, I personally really want the declarative tmpfiles/sysusers
definitions to be used in Debian soonish, and I want to have the most
robust implementation. The one in systemd is what most upstreams will
test with, so that appears to be the best choice, or rather the choice
with the smallest maintenance cost (looking through the codes, I also
vastly prefer the C implementation over the Bash one, as it looks much
cleaner. But since I write a lot more C than shell scripts and am more
experienced in the former, I may just be biased towards it naturally).
Ideally, space-optimizing the packaging a bit for containers (which
may not need logind for example, or all of the systemd generators and
FS manipulation helpers) may also help the alternative initsystems
usecase. So, if done well, everyone should be happy in the end.
Cheers,
Matthias
[1]: I tried to describe the functionality in as few words as
possible, please refer to the manpages for an in-depth explanation
about individual pieces. The interface stability and portability chart
is also always a good reference:
https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
---
I welcome VSRE emails. See http://vsre.info/
