:: Re: [Dng] epoch feature request
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Anto
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [Dng] epoch feature request


On 16/06/15 02:10, Steve Litt wrote:
> On Mon, 15 Jun 2015 22:48:00 +0200
> Anto <aryanto@???> 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


Thanks Steve,

Yes. I almost have everything to start trying to build epoch package,
*except* one important point that I have been asking for. That is the
mechanism to trigger an action to automatically update epoch.conf and
start the daemon when we install all packages with daemons that need to
be started/stopped at boot/shutdown time, *without* including epoch
specific files into those packages. So what I am basically looking for
is totally different approach than what Debian based distros have been
doing for other init systems, so that we don't need to patch all of
those packages with epoch specific files and re-build them.

I am starting to wonder that this approach might not be practically
achievable as package maintainers keep doing exactly the same all these
years for other init systems. If this would be the case, I really would
like to understand the reasons.

Cheers,

Anto