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