fungal_net wroteYou can do this with almost all running services, there is no need for s6/66, but to have the process/daemon/service/module restart after it fails and to maintain a session log for what happened when it did fail, you better use the service script. What happens when a service also needs a user's dbus session to be running for it to operate? If dbus goes down for some reason the process will spit out error messages, 66-inservice dbus-user will tell you why it failed. A 3rd reason is the environment within which a service is run. 66 formulates the appropriate environment for the service to run, which may need to be different than the default shell environment.
I have a conky module that greps processes of service of interest, like ssh. Sometimes I start my sshd tree for specific uses and when it finishes the tree goes down. But sometimes there are forked connections that remain hanging, from inappropriate closed connections, and I catch them this way, or some services fork themselves into more than one instances. Sometimes I may see my dhclient run as process 834 and all of a sudden I see the same process with a 5 digit process number. That means it restarted. 66-inservice will tell me why.
I started off with the service as below:
sudo 66-enable -t root -S pipewire, however i got the following error.
66-enable: fatal: unable to parse service file: /usr/lib/66/service/pipewire: or its dependencies
I was able to bring up cups using similar command and didn't get any error which made me believe pipewire's service is not needed OR maybe i did something wrong. So looked into other alternatives before i ended up with a login script.