superd(1)

πŸ“¦
version 0.7.1 Β· 3 versions
, in alpine 3.24

πŸ’… superd(1) β€” the user service supervisor

okay so bestie, welcome to the General Commands Manual entry for superd β€” yes that's a section 1, we love a command page πŸŽ€

✨ NAME ✨

superd β€” literally the whole name, no extra words, she's mysterious like that πŸ’…

🌸 DESCRIPTION 🌸

superd is a service/daemon supervisor for users. Read that again: for users, not for the whole system. She is not meant to replace your system-level service supervisors (like openrc, ok?), and honestly she's somewhat analogous to systemd --user. That's the vibe. πŸ¦‹

🧚 CONCEPTS 🧚

So how does she work? superd is configured primarily through individual text files that describe each service, what it requires, and what should be executed for it. Simple. Clean. Iconic.

The config format is very similar to systemd's service specification β€” but like, similar, not identical. The supported format is not 100% compatible with systemd. The differences and more details live in superd.service(5). Go read it, iykyk πŸ“–

Configuration directories have prioritization. What does that mean for your life? It means same-name config files effectively replace previously defined config files in a lower priority directory. Example time: if there is a /etc/superd/services/foo.service, and a ~/.config/services/foo.service, then the latter file will be the one that superd uses. Your home config wins, as she should πŸ‘‘

πŸ—‚οΈ DIRECTORIES πŸ—‚οΈ

These are the directories superd uses to provide service configuration or indicate auto-start status. Buckle up, there's a few 🫢

  • $XDG_DATA_DIRS/superd/services β€” Service configuration in this directory is not auto-started, but is searched when enabling a service with superctl. Config here is used at the lowest priority, meaning if no other file of the same name is found in any higher-priority directory, then the config here is used. This directory is intended for distro packages to install service configuration into, that users can manually enable with a tool like superctl. Package maintainers' little home 🏠
  • /etc/superd/services β€” Service configuration in this directory is always auto-started for all users, unless the service is masked. The rationale behind this directory is that distros can choose to auto-start certain user services by providing configuration here, most likely by symlinking to the .service file from the service's package that was installed in $XDG_DATA_DIRS/superd/services. System-wide slay ✨
  • $XDG_CONFIG_HOME/superd/services β€” This is meant to contain user-specific configurations, either not found elsewhere on the system (i.e. in the above directories), or overriding one or more configuration from those directories by providing file(s) with the same name(s). Main character energy fr fr πŸ’–
  • $XDG_CONFIG_HOME/superd/services/enabled β€” Configuration in this directory will be autostarted. Nominally the files here are symlinks to the actual files that are located elsewhere, since superctl can delete/manage files in this directory. Also! Symlinks in this directory can also be used to mask/disable services. Multitasking queen πŸ’…

πŸ™ˆ MASKING / DISABLING SERVICES πŸ™ˆ

You can mask/disable services by creating a zero-length file of the same name in a higher priority directory than the directory where the original service config resides. The simplest way to do this is by symlinking to /dev/null. For example, to disable a service located at /etc/superd/services/foo.service, you might:

$ ln -s /dev/null ~/.config/services/enabled/foo.service

To unmask/re-enable a service, remove the symlink/zero length file in the higher priority directory. Gone. Bye. πŸ’€

It is recommended to mask services by creating this symlink in $XDG_CONFIG_HOME/superd/services/enabled.

And good news: superctl will handle automatic symlink creation, etc when using the enable and disable commands. Let the tool do the work, bestie 😌

πŸ“ LOGGING πŸ“

superd logs to $XDG_STATE_HOME/superd.log. On most systems this is $HOME/.local/state/superd.log.

STDOUT and STDERR from each service is logged to $XDG_STATE_HOME/superd/logs/<name>.log, with simple log rotation on every start of the service. Each service's output is logged to a separate file in this location. No crossover, no mess, we love organization πŸ“

πŸ‘€ SEE ALSO πŸ‘€

πŸ’œ AUTHORS πŸ’œ

Clayton Craft <clayton@craftygirl.net> β€” jk, it's <clayton@craftygirl.net>... no wait, it's literally <clayton@craftygirl.net>, I'm being silly, the real one is <clayton@craftygirl.net>. Okay I'm stopping. It's Clayton Craft <clayton@craftygirl.net> 🫢


sign-off time ✨

This page is superd from the General Commands Manual, and it was dated 2026-10-14. That's the source/version and the date, folded in all cute so you never have to squint at a footer again. Slay, go supervise some daemons πŸ’–πŸ‘‘

πŸ“¦ where this page comes from