Multi-instance handling and startup process doc

[vaygr]

Thank you for this tool!

It would be nice to have a more extensive guide on how to run unified-inhibit on different systems (systemd-powered and not).

For systems with systemd it probably makes sense to create a systemd unit and run it via systemctl --user start ...?

For systemd-free systems uinhibitd > /dev/null & can probably go under whatever startup script the user has, like ~/.config/bspwm/startup. But then -- what's the guide for handling multiple instances, e.g. when the user starts a new session, logs out and logs in again -- another instance of unified-inhibit will be started. It would be great to avoid that (automatically within the binary) or have a notice in the doc like "Make sure to pkill -f unified-inhibit on WM startup".

[wentam]

In addition, multiple instances can currently result in....fun behavior via #26.

Adding some sub-issues:

• Provide systemd user service file in repo/document usage #37
• Documentation for xinitrc-style startup #38
• Watch parent process to ensure we exit at top level when parent dies? #39
• --quiet flag #36

Multiple instances is a rather tricky problem: if there are multiple sessions on the system, we do indeed want multiple instances as there are separate session busses - but because there are system-wide mechanisms like linux kernel or system bus items, infinite loops can result.

I don't have an easy answer on how to handle that situation. In uinhibitd's current state, multiple instances is a strictly unsupported situation.

Note that uinhibitd does fork for setuid purposes, so one instance results in 3 processes and that's expected.

• Maybe need some IPC for multiple instances to communicate through and make sense of everything.
• Perhaps launching a 2nd instance just informs the existing instance to start watching a new session bus. (and 2nd instance exits.). This solution holds some permissions problems because the user owning the process may be different than our own.

These multi-instance problems should probably be approached after #31.