[GTALUG] A few notes on SystemD

Christopher Browne cbbrowne at gmail.com
Thu Feb 18 18:34:21 UTC 2016


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?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20160218/c65650d6/attachment.html>


More information about the talk mailing list