<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>