diff --git a/notes/buses.md b/notes/buses.md new file mode 100644 index 0000000..ed43033 --- /dev/null +++ b/notes/buses.md @@ -0,0 +1,9 @@ +--- +title: 'Buses' +--- + +DBus - https://www.freedesktop.org/wiki/Software/dbus/ + +ubus (openwrt) - https://oldwiki.archive.openwrt.org/doc/techref/ubus + - ACLs + diff --git a/notes/criticism-of-systemd.md b/notes/criticism-of-systemd.md new file mode 100644 index 0000000..aa98e55 --- /dev/null +++ b/notes/criticism-of-systemd.md @@ -0,0 +1,9 @@ +--- +title: 'Criticism of systemd' +--- + +https://skarnet.org/software/systemd.html + +http://ewontfix.com/14/ + - keep supervision and system state management out of PID 1 + - there's a sample PID 1 implementation there diff --git a/notes/process-supervision.md b/notes/process-supervision.md new file mode 100644 index 0000000..310bfb9 --- /dev/null +++ b/notes/process-supervision.md @@ -0,0 +1,107 @@ +--- +title: 'Survey: Process Supervision' +--- + +# {{ page.title }} + +RedoxOS "fired" -- can't find code or a homepage? + +daemontools + - https://cr.yp.to/daemontools.html + + - services should be symlinked into a directory monitored by svscan + + - programs: + - svscanboot - starts svscan for /service, plus readproctitle for errors via ps + - svscan - "starts and monitors a collection of services." + - starts one `supervise` per service in a service directory (cwd) + - designed to run forever + - if `s` is a service, and `s/log` is a service, creates *two* + `supervise`s, with a pipe between them + - if any `supervise` terminates, it restarts it + - reuses the *same* pipe if restarting one end of a connected + pair of `supervise`s; this way no log messages are lost + - supervise - (re)starts ./run for a given service. Writes status to ./supervise/* + - svc - talks to a `supervise` + - svok - predicate: is `supervise` running for a service? + - svstat - list service status information for zero or more services (given explicitly) + - fghack - vile hack for antibackgrounding + - pgrphack - wrap a child in a new process group + + - readproctitle - takes stdin and puts it into its own command-line, to show up in ps output + - multilog - scriptable filterable actions on each line of stdin; e.g. append to log, replace contents of file etc. + - a "log" is a directory full of files with a special format + - tai64n - puts hex TAI timestamps on each line of stdin + - tai64nlocal - rewrites tai64n timestamps to human-readable + + - setuidgid - command wrapper for setting uid/gid + - envuidgid - command wrapper for setting environment variables UID and GID + - envdir - command wrapper for setting environment based on files in a directory + - softlimit - rlimit + - setlock - command wrapper for holding a "locked ofile" during the lifetime of the command + - what is an "ofile"? + + - hax to get daemontools svscan as PID 1: https://code.dogmap.org/svscan-1/ + - "For a clean shutdown, we want to kill each service and ensure + that its logger has written all the logs before killing the + logger." + +See "Artistic considerations" on https://skarnet.org/software/s6/why.html + +systemd + - sd_listen_fds() - LISTEN_PID, LISTEN_FDS, LISTEN_FDNAMES; https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html# + - sd_notify() - NOTIFY_SOCKET; https://www.freedesktop.org/software/systemd/man/sd_notify.html# + - sd_booted() - checks for /run/systemd/system/ + - sd_watchdog_enabled() - WATCHDOG_USEC, WATCHDOG_PID; https://www.freedesktop.org/software/systemd/man/sd_watchdog_enabled.html# + +Dinit https://github.com/davmac314/dinit + - startup notification lets you signal when the process is actually ready + - has something akin to dpkg's automatic/manual installation of + packages, but for service startedness. You can "release" a service + which is like "stop" but doesn't stop it if some dependent service + is using it. + - can "pin" a service in stopped or started state to prevent it from + starting/stopping. + +s6 has startup notification - is it compatible with systemd? + +Reasons why DBUS is the way it is (2015): https://lwn.net/Articles/641277/ + - "Message passing or IPC isn't really the most important part of + dbus. Process lifecycle tracking and discovery are more important. + However, by integrating the IPC system with the lifecycle tracking + you can simplify the overall system and avoid race conditions." + - "dbus has a lot of semantic guarantees, such as message ordering, + that reduce application complexity and therefore reduce code and + reduce bugs." - sounds familiar! + - "dbus names are directly modeled on X selections (see ICCCM)" - huh + +Horust + - https://news.ycombinator.com/item?id=22657301 + - https://horust.dev/ (broken?!?!) + - https://github.com/FedericoPonzi/Horust + +Integrate monit with syndicate-system? + +s6 - https://skarnet.org/software/s6/ - Laurent Bercot + - see also https://skarnet.com/projects/service-manager.html + - and https://archive.fosdem.org/2017/schedule/event/s6_supervision/ + + - oh! and this! https://skarnet.org/software/s6-rc/overview.html + - and https://skarnet.org/software/s6-rc/faq.html + + - redirfd trickery to get FIFOs set up for dependency resolution for + early logging: https://skarnet.org/software/s6/s6-svscan-1.html#log + -- in principle, could Syndicate dependency tracking take the place + of this? + - Maybe not because: "No logs are ever lost." (from https://skarnet.org/software/s6-linux-init/) + - On the other hand, maybe, if the actual mechanism for log + collection is a simple FIFO rather than full Syndicate (which + would be used for dependency tracking but not communication, for + this specific subtask). Keeps things UNIXy, keeps things + accessible, relies on the kernel for buffering stuff...? + +Logging in daemontools: + - https://cr.yp.to/daemontools/faq/create.html#runlog + - stdout is piped to stdin of the logger program + +runit - see https://docs.voidlinux.org/config/services/index.html diff --git a/notes/systemd-functions.md b/notes/systemd-functions.md new file mode 100644 index 0000000..8736590 --- /dev/null +++ b/notes/systemd-functions.md @@ -0,0 +1,106 @@ +--- +title: 'What does systemd do?' +--- + + - ac-power: reports whether A/C power is connected + - activate: do socket activation (setup sockets, exec() on activity) + - analyze: "profile systemd", various renderings and checks of system state and config + - ask-password: secure password entry for e.g. cryptsetup + - backlight: saves/restores backlight brightness at shutdown/boot + - basic + - architecture: show some abstraction over current architecture + - escape: string escaping for e.g. shell (blearghhh) + - log: various kinds of logging (incl. syslog, journal, etc) + - ratelimit: generic rate limiting datastructure and utilities + - reboot: system call + - util + - in_initrd() predicate + - virt: detects whether, and what kind of, virtualization is in effect + - binfmt: registers binfmts with the kernel + - boot: bootctl etc: communicate with EFI (?) about successful/failed boots + - boot/efi: an actual EFI implementation?? can't be? maybe it's an EFI boot program. I don't know enough about this + - busctl: introspect contents of D-Bus + - cgls: "Recursively show control group contents" + - cgroups-agent: sends a message to unix socket /run/systemd/cgroups-agent + - cgtop: "Show top control groups by their resource usage" + - core + - automount + - dbus-*, lots of dbus things, wonder what they all are + - dynamic-user: dynamic user/group ID allocation for, like, temporary use? + - efi-random: incorporate any random seed passed down from EFI + - execute: execute programs. lots of code here! + - job: a job/worker manager system + - detect-virt: detect virtualization + - firstboot + - fsck: runs fsck + - fstab-generator + - getty-generator + - hibernate-resume: a little initrd program that runs when restoring from hibernation! + - home: manage "home areas" + - hostname management + - hwdb: a hardware database + - id128: various identifiers + - machine ID + - boot ID + - invocation ID + - import: image importing for containers presumably + - initctl: like telinit I guess + - journal: journald, etc + - kernel-install: when would this be used? + - libsystemd: ? + - libsystemd-network: implementations of network protocols? + - dhcp, dhcp6 + - lldp + - libudev: ? + - login + - machine: machined: "Manage registrations of local VMs and containers" + - machine-id-setup: gives a machine a random persistent ID + - modules-load: load configured modules (for explicit loading, rather than on demand) + - mount: transient mounts + - network: various network services e.g. dhcp, lldp, route management, wifi management + - notify: "Notify the init system about service status updates" + - nspawn: "Spawn a command or OS in a light-weight container" + - nss-* + - oom: userspace OOM killer + - partition: partitioning tools + - pstore: ? + - random-seed: load/save random seed at boot/shutdown + - resolve: a full DNS resolver + - rfkill: radio power control + - run: "Run the specified command in a transient scope or service" + - shared + - shutdown + - sleep: enter sleep, hibernate, or both (?) + - sysctl: "Applies kernel sysctl settings" + - sysusers: creates system user accounts + - timedate, timesync: clock management, NTP etc + - tmpfiles: creates hierarchy under volatile/tmpfs areas of the filesystem (!) eg /run, /tmp etc + - udev (!!) + - vconsole: setup virtual consoles for e.g. utf8 mode + +Unit names: "plain", "template", "instance" (of template). + +Unit files: + - have a "scope" - "system", "global", "user". What does it mean? + - have a "type": + UNIT_SERVICE + UNIT_MOUNT + UNIT_SWAP + UNIT_SOCKET + UNIT_TARGET + UNIT_DEVICE + UNIT_AUTOMOUNT + UNIT_TIMER + UNIT_PATH + UNIT_SLICE + UNIT_SCOPE + - have a "state": + UNIT_ACTIVE + UNIT_RELOADING + UNIT_INACTIVE + UNIT_FAILED + UNIT_ACTIVATING + UNIT_DEACTIVATING + UNIT_MAINTENANCE + +Lots of code spent on argv parsing