doc/superctl: fix typos with --now
~craftyguy pushed to ~craftyguy/superd git
#45 "superctl status" doesn't print status for entire given list
~craftyguy commented on superd todo
superd is a user service supervisor that is only intended to be used for
supervising user services. It makes absolutely no attempt to replace init/pid
1, and should never be used do to that.
Service configuration uses systemd's .service files, so that it's low(er) effort to configure services. Many things intended to run as user services already have systemd config written. (Important: see later section on service configuration)
On startup, all service supervisors are started at once. The services run their commands if there are no dependencies specified, only services with dependencies wait for their dependencies to start up first.
This doesn't do anything except run some stuff, and manage the stuff it runs (restarting on failure, etc).
Building this project requires a Go compiler/toolchain and
To install locally:
$ make install
Installation prefix can be set in the generally accepted way with setting
$ make PREFIX=/some/location # make PREFIX=/some/location install
Other paths can be modified from the command line as well, see the top section of
Makefile for more information.
See relevant man pages:
Send patches and questions to the superd mailing list: https://lists.sr.ht/~craftyguy/superd
All patches should complete
make test successfully.
A script is provided in the repo to help with running
debug/testing. It will create a directory structure under
./home in the repo
and point the relevant
XDG_* vars there, so that
superd won't run services
~/.config and will instead load/run anything you place in
allows running superd/superctl in a way that won't clash with an existing
instance of superd (e.g. started by your login manager / DE.)
$ ./run superd -v * Creating /home/clayton/src/superd/home/runtime_dir * Creating /home/clayton/src/superd/home/config * Creating /home/clayton/src/superd/home export XDG_CONFIG_HOME='/home/clayton/src/superd/home/config' export XDG_RUNTIME_DIR='/home/clayton/src/superd/home/runtime_dir' export XDG_STATE_HOME='/home/clayton/src/superd/home' Log is at: /home/clayton/src/superd/home/superd.log
Optionally, delve can be invoked by setting
$ DEBUG=1 ./run superctl status export XDG_CONFIG_HOME='/home/clayton/src/superd/home/config' export XDG_RUNTIME_DIR='/home/clayton/src/superd/home/runtime_dir' export XDG_STATE_HOME='/home/clayton/src/superd/home' Log is at: /home/clayton/src/superd/home/superd.log Type 'help' for list of commands. (dlv)
There's an IRC channel on OFTC: #superd
And a mailing list: https://lists.sr.ht/~craftyguy/superd
There's also a Todo page: https://todo.sr.ht/~craftyguy/superd
However, please ask for assistance in IRC or on the mailing list, before filing a new issue at the project's todo page.
I don't always use distros that use systemd. I believe that declarative service config, while less powerful than writing piles of shell script, is easier to do and maintain long term. Almost everything else is either complicated to setup, can't handle dependencies, tries to do too much, or would require most folks to spend some non-trivial amount of time to learn to configure and "port" services too.
"Super" is short for "supervisor" or "superintendent." The "d" is added at the end because that's currently the cool trendy thing to do with daemons.
If you require a dbus user session, it's currently best to just start some
window manager (e.g. sway) with
dbus-run-session <wm exe>, and then have
superd run via whatever autostart mechanism the window manager provides.
For example, with sway:
$ cat ~/.config/sway/config ... exec superd ... $ dbus-run-session /usr/bin/sway
D-bus can also run as a superd service. By default, clients will attempt to
connect to the session socket
$XDG_RUNTIME_DIR/bus. A simple service that
runs the following command would listen on that same path:
dbus-daemon --session --address unix:path=$XDG_RUNTIME_DIR/bus
This has one major caveat: the
dbus-server will only emit readiness
notifications when built with systemd support, so it will not notify its
readiness on distributions that build
dbus-server without systemd support.
Ordering dependant services without readiness notification results in race conditions. For further discussion, see: https://todo.sr.ht/~craftyguy/superd/8