On Mon, 15 Jun 2015 22:48:00 +0200 Anto <arya...@chello.at> wrote: > I am not entirely sure what would happen if we purged sysvinit to > replace it with epoch, whether those packages will still generate > their specific scripts on /etc/init.d when we install them under > epoch or not. If they would still generate them, we could maybe > implement a mechanism to monitor /etc/init.d, automatically add the > daemon parameters into epoch.conf based on their "INIT INFO" when the > new script is being added into /etc/init.d and then start the daemon. > > There must be more elegant solution than that, but I am running out > of ideas due to my limited knowledge on this.
Early in my career I had a boss who was a full-on suit. But a smart one. He taught me that if you've captured all the necessary data, you can program it. I keep hearing about this LSB stuff in inits. Apparently that includes: # Provides: scriptname # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog I'm assuming Required-Start means the listed services must be ready before starting this one. I'm assuming Required-Stop means the listed services must be down before killing this one. The preceding is enough do to ordering and naming service in Epoch, and it's available from the sysvinit init scripts, which apparently the "upstreams" must provide in LSB fashion. OK, so you have that. There's other information you need. Should it respawn, or should it run-once? That might be available from systemd unit files, but the only way to get it from sysvinit init scripts is to analyze them as a human. You also need to know the user that the running service belongs to. I'm not sure where you'd get that: Check the sysetmd unit files. Basically, if I have all the necessary data, I can auto-make Epoch services, although the first few versions wouldn't totally replace hand-tweaking. You see what I mean though, if the data exists, the job can be done. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
