I like systemd myself, but I can certainly see why some people would not.
I'm running a recent git snapshot of it on Kubuntu 12.04 now, and it works fine -- though admittedly I had to write a wrapper for /sbin/initctl. I was never a fan of Upstart so I was keen to try this out, but I just can't get Fedora to grow on me. Also the Kubuntu crew are bros.
Do correct me where I'm wrong, but I believe systemd can run either as a system instance (PID 1), or as a user instance with only the privileges the user itself holds. Much like dbus.
Code:
$ systemd --help
systemd [OPTIONS...]
Starts up and maintains the system or user services.
-h --help Show this help
[...]
--system Run a system instance, even if PID != 1
--user Run a user instance
[...]
$ psgrep systemd
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 41184 3364 ? Ss Jun26 0:01 /bin/systemd
root 224 0.0 0.0 77896 2860 ? Ss Jun26 0:07 /lib/systemd/systemd-journald
root 245 0.0 0.0 28672 1664 ? Ss Jun26 0:00 /lib/systemd/systemd-udevd
root 723 0.0 0.0 30492 1544 ? Ss Jun26 0:00 /lib/systemd/systemd-logind
102 741 0.0 0.0 24832 2348 ? Ss Jun26 0:05 //bin/dbus-daemon --system --address=systemd: --nofork --activation=systemd
zorael 17912 0.0 0.0 33352 2056 pts/1 S+ 15:31 0:00 systemd --user
I have yet to use it in its user instance at all; I just ran it now to copy its ps entry here. I'll probably toy around with these KDE user units tomorrow.
In systemd's defense, all configuration files for services/mounts/sockets/timers/... ('units') are still humanly readable -- but they are not shell scripts, just like upstart's conf files aren't. You can still have several entries of ExecStartPre= commands that, when executed in sequence, halt (or not) the entire unit if they exit with errors. Like '/usr/bin/stuff --check-config', or simply '/bin/mkdir -p /run/lock/stuff'.
What systemd does make binary is a set of small helpers and daemons that cover certain basic and 'obvious' things. Instead of calling a shell script to put on your socks, you get it in compiled C. Luckily they're not incorporated into one huge /bin/systemd; most have unit files like every other service, ergo you can disable them like any other service. Some just seem to be internal helpers, some seem to be for shell scripting (?), some are definitely CLI tools.
Code:
systemd-ac-power # does udev magic and returns 0 if on AC
systemd-analyze # cheapo bootchart. "[...] determine system boot-up performance of the current boot."
systemd-ask-password # "[...] query a system password or passphrase from the user, using a question message specified on the command line. [...] The purpose of this tool is to query system-wide passwords -- that is passwords not attached to a specific user account. Examples include: unlocking encrypted hard disks when they are plugged in or at boot, entering an SSL certificate passphrase for web and VPN servers."
systemd-binfmt # it looks like it registers extra executable types and makes the kernel automagically call wrappers for them if need be? so ./file.exe would be run via Wine
systemd-cat # cats piped text or called args to the journal, see systemd-journald below
systemd-cgls # 'cgroup list'
systemd-cgroups-agent # cgroup release agent
systemd-cgtop # 'cgroup top'
systemd-coredump # saves a coredump if systemd crashes
systemd-cryptsetup # sets up encrypted block devices as you'd expect
systemd-cryptsetup-generator # "[...] translates /etc/crypttab into native systemd units"
systemd-delta # shows diff output of how user-modified units in /etc/systemd/{system,user} override those in /lib/systemd/{system,user}
systemd-detect-virt # "[...] detects execution in a virtualized environment. It identifies the virtualization technology and can distuingish full VM virtualization from container virtualization."
systemd-fsck # fsck logic at boot (at least)
systemd-fstab-generator # "[...] translates /etc/fstab [...] into native systemd units"
systemd-getty-generator # starts and manages ttys, be they virtual or console
systemd-hostnamed # "[...] mechanism to change the system hostname."
systemd-inhibit # "[...] used to execute a program with a shutdown, sleep or idle inhibitor lock taken. The lock will be acquired before the specified command line is executed and released afterwards."
systemd-initctl # "[...] implements compatibility with the /dev/initctl FIFO file system object, as implemented by the SysV init system."
systemd-journald # think syslog; "[...] system service that collects and stores logging data. It creates and maintains structured, indexed journals based on logging information that is received from the kernel, from user processes via the libc syslog(3) call, from STDOUT/STDERR of system services or via its native API."
systemd-localed # "[...] mechanism to change the system locale settings, as well as the console key mapping and default X11 key mapping."
systemd-loginctl # "[...] introspect and control the state of the login manager.", see below
systemd-logind # login manager that I have yet to learn to use
systemd-machine-id-setup # generates the /etc/machine-id file which "contains the unique machine id of the local system that is set during installation. [...] Programs may use this ID to identify the host with a globally unique ID in the network, that does not change even if the local network configuration changes."
systemd-modules-load # modprobes modules listed in /etc/modules-load.d/*.conf, like Upstart's module-init-tools does with /etc/modules
systemd-multi-seat-x # in preparation for multiseat; "this binary will go away as soon as X natively supports display enumeration with udev in a way that covers both PCI and USB."
systemd-notify # "[...] may be called by daemon scripts to notify the init system about status changes. It can be used to send arbitrary information, encoded in an environment-block-like list of strings. Most importantly it can be used for start-up completion notification."
systemd-nspawn # "[...] used to run a command or OS in a light-weight namespace container. In many ways it is similar to chroot, but more powerful since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host and domain name."
systemd-quotacheck # filesystem quota logic
systemd-random-seed # "[load] and save the system random seed at boot and shutdown"
systemd-readahead # readahead implementation (systemd-readahead{,-collect,-done,-drop,-replay})
systemd-remount-fs # "[...] early-boot service that applies mount options listed in fstab"
systemd-shutdown # shutdown logic
systemd-sleep # suspend logic
systemd-sysctl # configures sysctl parameters
systemd-system-update-generator # "[...] automatically redirects the boot process to system-update.target if /system-update exists."
systemd-timedated # "[...] used as mechanism to change the system clock and timezone, as well as to enable/disable NTP time synchronization."
systemd-tmpfiles # "[...] creates, deletes and cleans up volatile and temporary files and directories" as per configuration
systemd-tty-ask-password-agent # "[...] handles password requests of the system, for example for hard disk encryption passwords or SSL certificate passwords that need to be queried at boot-time or during runtime."
systemd-udevd # udev! http://lwn.net/Articles/490413
systemd-update-utmp # "[...] writes SysV runlevel changes to utmp and wtmp, as well as the audit logs, as they occur."
systemd-user-sessions # "[...] controls user logins. After basic system initialization is complete it removes /run/nologin, thus permitting logins. Before system shutdown it creates /run/nologin, thus prohibiting further logins. At the same time it also kills all user processes, so that system shutdown may proceed without any remaining user processes around."
systemd-vconsole-setup # sets console font and keymap
It all falls under the systemd project, but not all of that is /bin/systemd. So it's not a huge, monolithic binary blob trying to do everything -- they just rewrote some core stuff of the init process (eg. loading/saving random seed and modprobing modules) in C so as to stop needing shell scripts for those, and avoid the overhead those incur. Even if every distro were to immediately switch to systemd, you can still disable all of this and keep to conventional scripts through its sysv init.d compatibility. Inarguably scripts are easier to debug.
Admittedly, some parts of systemd reimplement existing solutions, though. systemd-readahead does away with ureadahead, timer units do away with cron, systemd-analyze does away with bootchart, and some others. At least it's modular so I can opt to disable the bits I don't want.
I'm not a packager, but I'd say it would sort of make sense to split these up a bit, so you'd have systemd, systemd-daemons and systemd-tools or so, to make it all a bit less intimidating.
Reply With Quote
Phoronix News Bot
Systemd Support For Managing User Sessions
Originally Posted by TobiSGD
Posting Permissions