initng and runscript

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

initng and runscript

Andrea Carpani
Hi all,

I'm looking around for alternatives to runscript style init scripts as I
don't like very much default gentoo scripts. While I do like the
depencencies stuff I still don't get why a "status" on a script gives
"started" if the process died badly, or why I need to manually do a zap
(can't restart do it for me?).

I think status should be implemented in each init script and should give
the real status of the service be it a ps|grep or whatever.

One more thing I'd like to see is a init controlled check on the death
of some daemons (sort of what daemontools does).

This is why I'm asking: has anyone here seriously tested/used initng new
scripts?

Thanks.
--

[hidden email]
http://www.carpani.net
Andrea Carpani
.a.c.

--
Andrea Carpani <[hidden email]>

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: initng and runscript

Patrick Lauer
On Thu, 2005-12-15 at 10:45 +0100, Andrea Carpani wrote:
> Hi all,
>
> I'm looking around for alternatives to runscript style init scripts as I
> don't like very much default gentoo scripts. While I do like the
> depencencies stuff I still don't get why a "status" on a script gives
> "started" if the process died badly, or why I need to manually do a zap
> (can't restart do it for me?).
The init-scripts only save state and don't check if the service is doing what it is supposed to do.

> I think status should be implemented in each init script and should give
> the real status of the service be it a ps|grep or whatever.
That would make init-scripts much more complicated and buggy I think.
While that would be optimal I don't see it happening in the near future.
Also it is really hard to reliably detect a service in a "working"
state, so you'd only check "does any process named sshd run?" which is
also mildly buggy :-) etc. etc.
It's not as easy as it sounds.

> One more thing I'd like to see is a init controlled check on the death
> of some daemons (sort of what daemontools does).
If I'm not mistaken a looooong time ago Gentoo used daemontools by default.

> This is why I'm asking: has anyone here seriously tested/used initng new
> scripts?
There are many different monitoring tools ... but none of them are easy
to integrate into baselayout.

Patrick
--
Stand still, and let the rest of the universe move

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [OBORONA-SPAM] initng and runscript

Alex Efros-3
In reply to this post by Andrea Carpani
Hi!

On Thu, Dec 15, 2005 at 10:45:34AM +0100, Andrea Carpani wrote:

> I'm looking around for alternatives to runscript style init scripts as I
> don't like very much default gentoo scripts. While I do like the
> depencencies stuff I still don't get why a "status" on a script gives
> "started" if the process died badly, or why I need to manually do a zap
> (can't restart do it for me?).
>
> I think status should be implemented in each init script and should give
> the real status of the service be it a ps|grep or whatever.
>
> One more thing I'd like to see is a init controlled check on the death
> of some daemons (sort of what daemontools does).
>
> This is why I'm asking: has anyone here seriously tested/used initng new
> scripts?

If you're looking for _reliable_ alternative for runscript style init scripts,
then you should look into 'runit' package. Runit is improved version of DJB's
'daemontools' package. I use it many years without any problems.

Check websites of daemontools and runit for all gore details why it's only
_reliable_ way to control services.

--
                        WBR, Alex.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: initng and runscript

Kalin KOZHUHAROV
In reply to this post by Patrick Lauer
Patrick Lauer wrote:

> On Thu, 2005-12-15 at 10:45 +0100, Andrea Carpani wrote:
>
>>Hi all,
>>
>>I'm looking around for alternatives to runscript style init scripts as I
>>don't like very much default gentoo scripts. While I do like the
>>depencencies stuff I still don't get why a "status" on a script gives
>>"started" if the process died badly, or why I need to manually do a zap
>>(can't restart do it for me?).
>
> The init-scripts only save state and don't check if the service is doing what it is supposed to do.
Yes, and that is by design.

>>I think status should be implemented in each init script and should give
>>the real status of the service be it a ps|grep or whatever.
>
> That would make init-scripts much more complicated and buggy I think.
> While that would be optimal I don't see it happening in the near future.
> Also it is really hard to reliably detect a service in a "working"
> state, so you'd only check "does any process named sshd run?" which is
> also mildly buggy :-) etc. etc.
> It's not as easy as it sounds.
>
>
>>One more thing I'd like to see is a init controlled check on the death
>>of some daemons (sort of what daemontools does).
Yes, use daemontools :-)

Gentoo fellow chutz has almost complete system under daemontools and I am following his way.
I hope to be able to provide a more general "all-in-/service" solutuion.

> If I'm not mistaken a looooong time ago Gentoo used daemontools by default.
Don't remember this, and I am using Gentoo for a long time...

>>This is why I'm asking: has anyone here seriously tested/used initng new
>>scripts?
>
> There are many different monitoring tools ... but none of them are easy
> to integrate into baselayout.
What else is there apart form daemontools, I know of any other..

Kalin.
/also known as korokoro or tar/
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: initng and runscript

Andrea Carpani
Il giorno ven, 16-12-2005 alle 01:22 +0900, Kalin KOZHUHAROV ha scritto:

> > >I'm looking around for alternatives to runscript style init scripts as I
> > >don't like very much default gentoo scripts. While I do like the
> > >depencencies stuff I still don't get why a "status" on a script gives
> > >"started" if the process died badly, or why I need to manually do a zap
> > >(can't restart do it for me?).
> > The init-scripts only save state and don't check if the service is doing what it is supposed to do.
> Yes, and that is by design.

I know. I miss, though, the possibility to create my own "status"
function that at least lets me know if the process is there. I haven't
been able to override the "status" cleanly.

> >>I think status should be implemented in each init script and should give
> >>the real status of the service be it a ps|grep or whatever.
> > That would make init-scripts much more complicated and buggy I think.
> > While that would be optimal I don't see it happening in the near future.
> > Also it is really hard to reliably detect a service in a "working"
> > state, so you'd only check "does any process named sshd run?" which is
> > also mildly buggy :-) etc. etc.
> > It's not as easy as it sounds.

What I was thinking was something like other init systems do: each
script can have a "status" overridden at init.d script level that can do
checks: wether this is a single ps|grep or something more complex it's a
packager's choice.

> >>One more thing I'd like to see is a init controlled check on the death
> >>of some daemons (sort of what daemontools does).
> Yes, use daemontools :-)

I'll give it a shot asap.

> >>This is why I'm asking: has anyone here seriously tested/used initng new
> >>scripts?
> > There are many different monitoring tools ... but none of them are easy
> > to integrate into baselayout.
> What else is there apart form daemontools, I know of any other..

There are initng scripts found here.
http://initng.thinktux.net/index.php/Main_Page
Maybe someone has tested them?

--
Andrea Carpani <[hidden email]>

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: [OBORONA-SPAM] initng and runscript

Andrea Carpani
In reply to this post by Alex Efros-3
Il giorno gio, 15-12-2005 alle 13:27 +0200, Alex Efros ha scritto:

> If you're looking for _reliable_ alternative for runscript style init scripts,
> then you should look into 'runit' package. Runit is improved version of DJB's
> 'daemontools' package. I use it many years without any problems.
>
> Check websites of daemontools and runit for all gore details why it's only
> _reliable_ way to control services.

Thanks I'll try it.

--
Andrea Carpani <[hidden email]>

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: [OBORONA-SPAM] initng and runscript

Eric Brown-5
It's not just init scripts that are designed poorly, it's applications
that fail to daemonize and dont' return non-zero.  (like apache-1.3,
ntp-date, snort, etc.. most servers).

I think the new baselayout has some adjustable sleep/checks on by
default, but I haven't tries it yet.  I suppose that would work by
having the init script sleep for a short time, then check to see if a
certain process is running (a dirty hack that's frowned updon by
some)...

Anyway, I really think this is something worth looking into, either as
a separate package that implements some kind of monitoring functions
in init scripts, or as a basic set of monitoring functions that are
included in baselayout for developers to optionally use.  While there
are options like daemontools and rmon? I don't think they provide a
very robust solution to this problem.

Here's an idea:

Have users emerge a program that can do some basic things:

1) check config scripts of running services for variables like:
    CHECK_COMMAND
    SLEEP_TIME
    INIT_SLEEP
    IF_DOWN_DO_THIS

   (those variables could optionally be implemented per package, or
explicitly disabled, they would have sane defaults in a central .conf
file for this enhancement package)

2) is a cron job/daemon that automatically checks all running apps in
the current runlevel,  can report problems (send emails, log stuff,
etc), can send heartbeat, etc..

3) is well documented in the gentoo handbook since it's probably a
vital component


To me this kind of thing is probably simple, unixish, and robust
enough for most of our needs...

Any thoughs?

On 12/16/05, Andrea Carpani <[hidden email]> wrote:

> Il giorno gio, 15-12-2005 alle 13:27 +0200, Alex Efros ha scritto:
>
> > If you're looking for _reliable_ alternative for runscript style init scripts,
> > then you should look into 'runit' package. Runit is improved version of DJB's
> > 'daemontools' package. I use it many years without any problems.
> >
> > Check websites of daemontools and runit for all gore details why it's only
> > _reliable_ way to control services.
>
> Thanks I'll try it.
>
> --
> Andrea Carpani <[hidden email]>
>
> --
> [hidden email] mailing list
>
>

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: initng and runscript

Kalin KOZHUHAROV
Eric Brown wrote:
> It's not just init scripts that are designed poorly, it's applications
> that fail to daemonize and dont' return non-zero.  (like apache-1.3,
> ntp-date, snort, etc.. most servers).
Yeah, that is the real problem, but that is not fixable immediately.

> I think the new baselayout has some adjustable sleep/checks on by
> default, but I haven't tries it yet.  I suppose that would work by
> having the init script sleep for a short time, then check to see if a
> certain process is running (a dirty hack that's frowned updon by
> some)...
>
> Anyway, I really think this is something worth looking into, either as
> a separate package that implements some kind of monitoring functions
> in init scripts, or as a basic set of monitoring functions that are
> included in baselayout for developers to optionally use.

> While there are options like daemontools and rmon? I don't think they
> provide a very robust solution to this problem.
Can you elaborate on this? What is wrong with daemontools?

http://cr.yp.to/daemontools/faq/create.html#why

> Here's an idea:
>
> Have users emerge a program that can do some basic things:
emerge daemontools


> 1) check config scripts of running services for variables like:
>     CHECK_COMMAND
svstat /service/daemon

>     SLEEP_TIME
If I get you right, this is hard coded to 1 second for supervise.

>     INIT_SLEEP
If I get you right, this is hard coded to 1 second for supervise.

>     IF_DOWN_DO_THIS
Not sure how important is this, but flexibility can be achieved inside the ./run script of the
daemon. The normal thing is to start it again.
svc -u /service/daemon

>    (those variables could optionally be implemented per package, or
> explicitly disabled, they would have sane defaults in a central .conf
> file for this enhancement package)
This can be worked on, the start is sys-process/daemontools-scripts.

> 2) is a cron job/daemon that automatically checks all running apps in
> the current runlevel,  can report problems (send emails, log stuff,
> etc), can send heartbeat, etc..
Can you trust cron, started from a init script?
Instead a script started under supervise, as simple as this:
#!/bin/bash

sleep 60;
`svstat /service/* |grep down >/dev/null` && \
        echo "Something is wrong" | your_favourite_mailer_here

(The above is not tested, just thought of. Feel free to improve).
(Like there can be intentionally down-ed services -e /service/daemon/down)

> 3) is well documented in the gentoo handbook since it's probably a
> vital component
http://cr.yp.to/daemontools.html is a good start, in can be improved for sure.

> To me this kind of thing is probably simple, unixish, and robust
> enough for most of our needs...
>
> Any thoughs?
Don't top-post :-)

Kalin.
/known also as Korokoro or tar/

P.S. Whose MTA changes the subject with [OBORONA-SPAM] ? Please remove that; use a custom header
instead.

--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: [OBORONA-SPAM] Re: initng and runscript

Alex Efros-3
Hi!

On Wed, Dec 21, 2005 at 12:51:52PM +0900, Kalin KOZHUHAROV wrote:
> >     IF_DOWN_DO_THIS
> Not sure how important is this, but flexibility can be achieved inside the ./run script of the
> daemon. The normal thing is to start it again.
> svc -u /service/daemon

runit package provide ./finish scripts for this task.

> P.S. Whose MTA changes the subject with [OBORONA-SPAM] ? Please remove that; use a custom header
> instead.

It's not MTA. This tag added to subject by webmail 'mail.yandex.ru', so I
receive emails from maillist already with that tag and it's automatically
included in my replies. Sorry.

--
                        WBR, Alex.
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: initng and runscript

Eric Brown-5
In reply to this post by Kalin KOZHUHAROV
On 12/20/05, Kalin KOZHUHAROV <[hidden email]> wrote:

> Eric Brown wrote:
> > It's not just init scripts that are designed poorly, it's applications
> > that fail to daemonize and dont' return non-zero.  (like apache-1.3,
> > ntp-date, snort, etc.. most servers).
> Yeah, that is the real problem, but that is not fixable immediately.
>
> > I think the new baselayout has some adjustable sleep/checks on by
> > default, but I haven't tries it yet.  I suppose that would work by
> > having the init script sleep for a short time, then check to see if a
> > certain process is running (a dirty hack that's frowned updon by
> > some)...
> >
> > Anyway, I really think this is something worth looking into, either as
> > a separate package that implements some kind of monitoring functions
> > in init scripts, or as a basic set of monitoring functions that are
> > included in baselayout for developers to optionally use.
>
> > While there are options like daemontools and rmon? I don't think they
> > provide a very robust solution to this problem.
> Can you elaborate on this? What is wrong with daemontools?
>
> http://cr.yp.to/daemontools/faq/create.html#why
>
> > Here's an idea:
> >
> > Have users emerge a program that can do some basic things:
> emerge daemontools
>
>
> > 1) check config scripts of running services for variables like:
> >     CHECK_COMMAND
> svstat /service/daemon
>
> >     SLEEP_TIME
> If I get you right, this is hard coded to 1 second for supervise.
>
> >     INIT_SLEEP
> If I get you right, this is hard coded to 1 second for supervise.
>
> >     IF_DOWN_DO_THIS
> Not sure how important is this, but flexibility can be achieved inside the ./run script of the
> daemon. The normal thing is to start it again.
> svc -u /service/daemon
>
> >    (those variables could optionally be implemented per package, or
> > explicitly disabled, they would have sane defaults in a central .conf
> > file for this enhancement package)
> This can be worked on, the start is sys-process/daemontools-scripts.
>
> > 2) is a cron job/daemon that automatically checks all running apps in
> > the current runlevel,  can report problems (send emails, log stuff,
> > etc), can send heartbeat, etc..
> Can you trust cron, started from a init script?
> Instead a script started under supervise, as simple as this:
> #!/bin/bash
>
> sleep 60;
> `svstat /service/* |grep down >/dev/null` && \
>         echo "Something is wrong" | your_favourite_mailer_here
>
> (The above is not tested, just thought of. Feel free to improve).
> (Like there can be intentionally down-ed services -e /service/daemon/down)
>
> > 3) is well documented in the gentoo handbook since it's probably a
> > vital component
> http://cr.yp.to/daemontools.html is a good start, in can be improved for sure.
>
> > To me this kind of thing is probably simple, unixish, and robust
> > enough for most of our needs...
> >
> > Any thoughs?
> Don't top-post :-)
>
> Kalin.
> /known also as Korokoro or tar/
>
> P.S. Whose MTA changes the subject with [OBORONA-SPAM] ? Please remove that; use a custom header
> instead.
>
> --
> |[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
> +-> http://ThinRope.net/ <-+
> |[ ______________________ ]|
>
> --
> [hidden email] mailing list
>
>

What I don't like about daemontools is that I like our current init
system, and daemontools just totally replaces it.  With a little
effort, it might be possible to simply supplement the init script
resources we already have.  I would really miss some of the stuff the
gentoo devs made easy for us: automatic dependency handling, ease of
use w/rc-update, simple configuration symatics for a wide range of
daemons (network stuff and drive mounting stuff)...

Anyway, I'm glad you brought up daemontools, there's a lot to learn
from it.  Maybe approaching this problem from the other direction
would even be a good idea: How can we enhance daemontools to create a
new gentoo init script system that's every bit as friendly as the
current one?

--
[hidden email] mailing list