(15-06-2017, 02:49 PM)venam Wrote:

(15-06-2017, 02:35 PM)z3bra Wrote: easier than anything else really. No complex variable, no surprise on what will run, no hidden framework to source... Just a shell script, that you can run on its own to test it

However there are two things you are missing:

• The role of an init system is not limited to the role of a service manager, it's only one feature amongst others it can provide.
  
• The role of a service manager is not limited to simply starting the services it might also do the following:
  • Start daemons (whole detachment process)
    
  • Have some sort of order, be it synchronous and deterministic, or asynchronous dependency based, plus:
    • could be according to a simple list
      
    • could be according to some dynamic factors/events (socket, devices connected, new mount point, time based(periodic), file system changes, etc..)
      
  • Control and monitor the daemons (centralized way to do that)
    
  • Recover in case of crashes
    
  • Provide debug logs (dumps, traces) in case of crash
    
  • It could have a centralized log mechanism
    
  • Integrate some sort of IPC
    

The init systems I mentioned are indeed not perfect (none of them is actually, which is why we're facing a war of inits).
First of all, I don't think it's the init job to handle services. Its role is to bring up the system. What happens next is irrelevant to the "init".
For services, you're right, today, only systemd can start a service when a special path is mounted, or a socket is created. But is it the right way to do it? In the end, is a mount point semantically different from a "network" service? IMO, they should all be treaten the same, using a mechanism similar to the need(8) idea (see https://web.archive.org/web/200104281211...ot-scripts)

basically, your script could be this (note that mpd flags are random here, I don't know.them):