[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