If I had to be and admin of mixture of linux distributions I would probably use 'service', instead of remembering all commands suited for different init flavours and checking on which box I'm about to run a command.
But in such a case I probably would not care what kind of init subsystem is running on my box. I would not wait for Devuan to get something with sysvinit. So if I'm stick to sysvinit why I am to use 'service'? Why learn another wrapper name which does one thing more if I can always do env /etc/init.d/blabla start If I want to have clean environment when starting this script. But I cannot imagine why should I even use 'env' command (in ideal world). The init script should use it if it is important that the environment is cleaned up before starting the application daemon ( or service if you want to call it this way). This is responsibility of application maintainer to provide 'idiot proof' starting script. The assumption that 'service' command will prepare environment is IMHO a mistake, cause the init script _can_ be executed directly as it was done for a long time, before 'service' command was introduced. Yes, I think it was bad design decision to make 'service' command to cleanup environment, not leaving this task to init script, because of legacy of /etc/init.d , and because the init.d scripts can be executed directly anyway. If 'service' command was running scripts from other folder/schema/subsystem, but not from well known /etc/init.d, than I would say I should obey the rules of the new command, once decided i want to use it. So, please make the system suit your needs, but do not assume what are mine. :) -- regards piotr _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
