earnestly/home

General system configuration

home's Issues

Runsvdir still needs to be started manually

On my system runit's runsvdir has to be explicitly run after login as I've not managed to use systemd to start this as a per-user system service and would prefer to avoid adding this kind of logic to my shell's profile.

However if I cannot convince systemd to run this as a system service with User=%i instantiation I'll have to probably involve the login shell with something like:

if hash runsvdir 2> /dev/null && ! pgrep -U "$UID" -x runsvdir; then
    runsvdir "$LOCALDIR"/service &
fi

There's also the potential to use pam's pam_exec but that might involve even more wrappers.

sx needs to conditionally use -logfile

So Xorg has two modes of operation: privileged and non-privileged.

Unfortunately we can't use -logfile when the server is running in privileged mode, for example, when using the nvidia display drivers.

The problem comes when trying to detect if the Xorg server is going to need privilege. By default /etc/Xwrapper.config uses needs_root_rights = auto meaning that while Xorg can auto-detect, we can't use this file to do our own detection. This is irrelevant anyway as /etc/Xwrapper.config need not exist, and usually doesn't.

Another possible solution is to check for the presence of nvidia on our system and simply assume we're in privileged mode and not adding -logfile to the command-line. This is obviously a terrible idea as it hardwires assumptions about the relationship between nvidia and Xorg along with denying use cases such like Optimus or PRIME without even more heuristics based fudging.

A simple, but inelegant solution to this might be simply offering a command-line flag which explicitly indicates which mode we're going to run in; e.g. sx -p. This will require some command-line juggling, unfortunately.

Runsv doesn't seem to recall previous state

Starting runsvdir for my services will bring up all services even if I had previously set their state to down.

I'm not sure if this is due to systemd ungracefully SIGKILLing my user's session scope or an issue with runit.