superd/Systemd conflicting user services management

Services managed by superd should not be hard-coded in the start hook. Instead, it should be managed by symlinks in superd's configuration.

A separate install target will allow non-systemd distros to enable these services, and systemd distros to skip enabling them.

Related: https://todo.sr.ht/~mil/sxmo-tickets/175 https://todo.sr.ht/~mil/sxmo-tickets/176

Assigned to
5 months ago
5 months ago
No labels applied.

~earboxer 5 months ago

Ideally, I'd like to remove all superctl start statements from our code, but that wouldn't work well with sway/dwm live-switching.

Some services we need to run with superd. Is a good division of these the ones prefixed with "sxmo", and the ones not?

It looks like maybe just mmsd/vvmd are services we have toggles for that don't start with "sxmo" (i.e. systemd users would want systemd to manage). ~aren is that right?

~earboxer 5 months ago

https://lists.sr.ht/~mil/sxmo-devel/patches/33707 Is one part of this.

Remaining changes to allow systemd usage for some user programs:

  • [ ] get DE-specific tasks launched by configuration (instead of start hook) e.g. mako/(dunst, unclutter, autocutsel)
  • [ ] allow toggling vvmd/mmsd with systemd (and change them to be started by superd configuration, rather than conditionally by the start hook?)
  • [ ] Have callaudiod started by superd configuration (instead of after the sleep 5 in the start hook)
  • [ ] (optional) Also prune the De-specific superctl start sxmo* services from the start hook, for cleanliness (using superd config instead).

~earboxer 5 months ago

It strikes me that the second point above has already been rejected in the past.

To avoid adding systemd calls into our code, we need a distro-agnostic way to tell vvmd (and mmsd) that we gave it a new config. (something to work on upstream).

~aren 5 months ago

Limiting the number of calls to superd would be great for portability, on arch I have to be very careful to remove pipewire, mmsd, and vvmd from my start hook, because otherwise superd will fail to start them (because systemd already has), and enter an infinite restart loop which uses up a bunch of cpu power.

If superd could handle service dependencies it would be possible to create a "meta-service" for sway / dwm specific services. I don't think we can remove calls completely, but that would probably make it possible to have just a few.

Mmsd and vvmd have a dbus interface for configuration, that (iiuc) is preferred for configuration because it doesn't require restarting it. It's possible we could switch to that (perhaps by adding support to mmsctl?), although it would sort of be trading one mess for another.

Register here or Log in to comment, or comment via email.