I had prepped a few notes at the last meeting with a view to saying a wee bit about SystemD; apparently my name never got picked by the 1D20. I have been collecting notes for a couple of months, particularly with a view to the "Stupid SystemD tricks" part. There's a lot there; perhaps this "memory dump" will help others recognize things too. The other pointed interesting bit is in recognizing the differences between "political parties" on the merits/demerits. There seem to be sizable sets of people that have stopped thinking/listening, which is pretty unfortunate, and in sad keeping with shapes of political movements elsewhere. * SystemD debates [[http://uselessd.darknedgy.net/ProSystemdAntiSystemd/][Why Pro SystemD and Anti SystemD people cannot get along]] - It's actually mostly politics, just not of one of the parties that they recognize - Proponents tend to have afiliation with "modern desktop" - Want more interoperability - Sure, somewhat more "Windows like" - Seek reducing interface complexity but not implementation complexity - Computers as appliances rather than tools - Detractors often come from niche distributions - Less interested in desktop advances - Care about malleability more than user friendliness - Computers as tools - The fight is more about desktop vs minimalism - A moderate annoyance: systemd includes *journald*, which does logging - Why not use *syslog*??? - Because you /cannot/ use *syslog* to log things until *syslog* is running - And *syslog* is not running until a whole bunch of /other/ services get started, by *systemd* - Ergo, *systemd* needs a logging system /that is not syslog/ - It may be desirable to /forward/ responsibility for logging to *syslog*, /once it is running/, and *systemd* supports that * SystemD concepts :systemd: ** Units - objects that systemd can manage - standardized representation of system resources - like services, jobs in init systems - can use units to abstract services, network resources, filesystem mounts, resource pools - Various activation methods - socket based :: start unit upon accessing a socket, like xinetd - bus based :: start unit when DBus request is submitted - path based :: start unit when inotify indicates a path is available - device based :: start unit when hardware is available based on udev events - With dependency mapping/ordering - Various types - ~.service~ :: indicates how to manage a service/application, including - how to start/stop the service - when service should be automatically started - dependency and ordering information for related software - ~.socket~ :: indicates network/IPC socket or FIFO that is to be used for socket-based activation - points to ~.service~ file - ~.device~ :: indicates a device needs systemd management - often needed for ordering, mounting, accessing the device - ~.mount~ :: defines a mountpoint to be managed by systemd - named after mount path with slashes transformed to dashes - ~/etc/fstab~ entries automatically get such units (how???) - ~.automount~ :: indicates mount points to be automatically mounted - refers to a ~.mount~ file - ~.swap~ :: indicates swap space - ~.target~ :: target unit provides synchronization points for other units when changing state - seems to be a way of indicating dependencies a bit abstractly - ~.path~ :: indicates cases where, when a path reaches desired state, the service will be started - uses inotify to watch for changes - e.g. - do not start up /postgresql-database/ until the filesystem with data has been mounted - ~.timer~ :: indicates a timer for systemd to manage indicating when the service unit will be started - can be used to do things like cron jobs - ~.snapshot~ :: - ~.slice~ :: associates with Linux Control Group nodes to restrict access to resources to processes in the slice - so, security-ish??? - samples on Debian say NOTHING about this, so perhaps they're no-ops? - ~.scope~ :: help (how?) to manage system processes created externally (from systemd?) - Default unit files in ~/lib/systemd/system~ - Customize into ~/etc/systemd/system~ *** Directives - unit section :: defines metadata - Description :: what is this? - Documentation :: reference - Requires :: units required before this one (failure to have them indicate this unit fails) - Wants :: units wanted (less strict) - BindsTo :: this unit should terminate when another one terminates - Before :: units specified must not start until after the present one is started, but this is not indicating dependency - After :: this unit must not start until the specified units are started - Conflicts :: mutual exclusions of units - Condition :: things to test prior to starting the unit - failure leads to graceful skipping of the unit - PathExists - Capability - PathIsReadWrite - DirectoryNotEmpty - FileIsExecutible - KernelCommandLine - NeedsUpdate - PathIsDirectory - PathIsMountPoint - PathIsSymbolicLink - Virtualization - Assert :: failure of conditions lead to reporting failure of the unit - Various other sections specialized to various sorts of units - Transaction manager - Jobs - Job queueing - Tasks - What is journald? ** Translating former understandings to SystemD - Configuration that you mess with tends to be in ~/etc/systemd/system~ - Finding all services #+BEGIN_EXAMPLE # systemctl list-units #+END_EXAMPLE - This lists loaded units, and does so if you omit ~list-units~ - ~systemctl list-units --all~ :: list non-loaded units - ~systemctl list-unit-files~ :: list unit files - ~systemctl list-dependencies~ :: list the hierarchy of dependencies - and other things can be listed - The common start/stop/restart targets work - ~systemctl start boa~ - ~systemctl stop boa~ - ~systemctl reload boa~ - ~systemctl force-reload boa~ - More operations that should be obvious-ish - ~systemctl cat boa~ :: list the unit files - ~systemctl disable boa~ :: disable boa - ~systemctl reenable boa~ :: reenable boa - ~systemctl enable boa~ :: enable boa - ~systemctl edit boa~ :: edit boa units (copying to ~/etc/systemd/system~ if needed) - ~systemctl show boa~ :: show environment values and such * SystemD Bibliography :systemd: - [[https://n0where.net/understanding-systemd/][Understanding SystemD]] * Stupid SystemD Tricks ** Emacs as a service - Set up a unit file #+BEGIN_EXAMPLE [Unit] Description=Emacs: the extensible, self-documenting text editor [Service] Type=forking ExecStart=/usr/bin/emacs --daemon ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)" Environment=SSH_AUTH_SOCK=%t/keyring/ssh Restart=always [Install] WantedBy=default.target #+END_EXAMPLE ** Use SystemD rather than crontab? It seems as though the job information needs to be integrated into the "central" systemD configuration, so this is more or less a contraindicated thing to do. There are examples in documentation of running system cleanup tasks as SystemD-controlled jobs, so that is fairly reasonable to do. But I'd kind of like it if I could use SystemD to do things like... - starting up my favorite file downloader daemon - start up user space daemons running /at user level/ - run user-oriented scheduled tasks And this seems totally unnatural to do via SystemD. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"