Support other init systems than systemd

[danimesq]

.deb packages installer is requiring systemd:

Installing AppImageLauncher as interpreter for AppImages

• systemctl restart systemd-binfmt /var/lib/dpkg/info/appimagelauncher.postinst: line 25: systemctl: command not found dpkg: error processing package appimagelauncher (--configure): subprocess installed post-installation script returned error exit status 127 Errors were encountered while processing: appimagelauncher E: Sub-process /usr/bin/dpkg returned an error code (1)

[TheAssassin]

@DaniellMesquita I followed the proposal from #283 which suggests adding an explicit dependency rather than trying to remove the dependency. I chose systemd for both being widespread and making running user-level daemons a lot easier than whatever else I could find. I did not feel like writing my own user-space daemon management once again...

Your distribution is free to add support for alternative init systems (yes, I know that involves patching a few sections in the code as well). It's not too hard I guess.

Also, contributions welcome! If there's anyone interested in abstracting the daemon handling and creating some sort of daemon system adding a middleware API that can deal with different backends, PRs highly welcome, that'll increase the overall code quality as well.

[danimesq]

Did you heard of RC?

[TheAssassin]

RC? You mean the init system from System V? Yes, of course.

[danimesq]

Make AppImage modular, compatible with RC and not requiring systemd.

[TheAssassin]

I cannot maintain any init systems other than systemd myself. It's in widespread use. Other init systems are only used in more (no offense) "esoteric" setups nowadays.

PRs welcome, but I can't work due to time constraints on that and also don't see a major benefit for most users.

[ghost]

FWIW, I don't think RC manages everything, except giving people the will to kill someone or something, allowing to kill a random process because one do kill $(cat /var/run/foo.pid) but the original process was closed without removing the pid file while a process spawned and, oh the bad luck!, have that very same PID or other stuff like that.

I'm used enough to run my things by hand (understand: I'm not a user of this application), so I won't do the patch, but since TheAssassin asked me to share knowledge about "how to have a user-level service manager without systemd", here's my input, to whoever is really interested in having the feature.

Basically, all daemontools children should be able to do it. Daemontools is only that: a service manager. It's children are usually init systems which include, one way or another, a service manager. For what I know, which is runit, that service manager is a separated binary, which is usually started by init. To make it simple (interested people will have to do their homework):

mkdir /etc/sv/a_freaky_user
cat > /etc/sv/a_freaky_user/run <<EOF
#!/bin/sh
mkdir ~a_freaky_user/sv
exec chpst -u a_freaky_UID:a_freaky_GID -P runsvdir ~a_freaky_user/sv
EOF
chmod +x /etc/sv/a_freaky_user/run

Then, create run files as a_freaky_user in ~a_freaky_user/sv and make them executable. Service created. User can handle it with the sv command, which have various subcommands: status, start, stop, restart, etc. To allow sv to know where to search for that directory, caller must define the SVDIR variable. For example: SVDIR=~a_freaky_user/sv sv restart an_endlessly_looping_daemon.

That's the idea. Now, I don't know how to integrate it in any distro or projects. I know it works though, because I use it on my own server and PC, which are running debian 10.