$HOME FHS & init for user-oriented systems - Servers Administration, Networking, & Virtualization

Users browsing this thread: 2 Guest(s)
freem
Nixers
Hello.

I am thinking to rework how I manage my $HOME and user sessions, notably, I want to have things there handled with my beloved runsvdir(1).
Examples of daemons/applications that one would maintain alive: MUA (like claws-mail), IRC client, music player, urxvtd, window manager (i3).
This list is not complete, and I think many of my activities could/should be done by real daemons with which I'd interact "normally" (I'm thinking to build a daemon to register songs I like which come from mpd via netradios, for example).

Some of the problems I foresee here:

* management files (daemon status) should be in a tmpfs (persistance here would be annoying at best), yet only root can do that. I could just mkdir in /tmp, but that's quite dirty and fragile imo. /dev/shm would be a better place, but it's not portable. /run is owned by root, so no way here neither.

* starting multiple sessions might launch multiple runsvdir, will make things a mess. Can probably be worked around a way or another... Stopping a session poses the same problems. I would prefer to avoid using elogind, to rely on simpler tools. I see several places on which I could work here: runsv works with "constructors" and "destructors" to reuse the C++ terms, so maybe I could use utmp related tools here?

* make my $HOME a worse mess than it already is.

* processes escape their parent, notably i3's children. That's really annoying... maybe can be solved using namespaces on linux? I'm not really sure what those are, but chpst(1) proposes a way to start the command in a new process group, could that avoid the problem?

So, how do you guys handle those problems? What's your approach on them?


Messages In This Thread
$HOME FHS & init for user-oriented systems - by freem - 09-12-2020, 02:54 PM