[gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Hallgrimur H. Gunnarsson]

Hello friends !

I'd like to propose a new USE flag.

On my systems I've added a 'daemontools' USE flag
as an alternative to the current init.d for
service management. To be a true metadistribution,
it doesn't seem fair to let init.d have a monopoly
on providing service management for packages.

For those who haven't heard of it before, daemontools
is a process supervisor that can manage services.
For more information see http://cr.yp.to/daemontools.html

Integration of this functionality into ebuilds is in
most cases very trivial. Packages that wish to
provide daemontools USE flag support provide
a 'run' file, that is copied to a service directory,
/etc/daemontools/servicename, or something in that
direction.  We could even have some automated facility
for preparing service directories.

People can then choose what to use for running a particular
service, /etc/init.d or linking the service directory into
/service if the package provides daemontools support.

I've opened a bug for this (#28294), so what do people
think of this?

-- hhg


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Matt Thrailkill]

Is this effectively a new system of init-scripts?

If so.. I think it'd be cool to write some bsd-style init-scripts to add
to the variety.

On Tue, 9 Sep 2003 21:11:12 +0000
"Hallgrimur H. Gunnarsson" <hhg@data.is> wrote:

> Hello friends !
> 
> I'd like to propose a new USE flag.
> 
> On my systems I've added a 'daemontools' USE flag
> as an alternative to the current init.d for
> service management. To be a true metadistribution,
> it doesn't seem fair to let init.d have a monopoly
> on providing service management for packages.
> 
> For those who haven't heard of it before, daemontools
> is a process supervisor that can manage services.
> For more information see http://cr.yp.to/daemontools.html
> 
> Integration of this functionality into ebuilds is in
> most cases very trivial. Packages that wish to
> provide daemontools USE flag support provide
> a 'run' file, that is copied to a service directory,
> /etc/daemontools/servicename, or something in that
> direction.  We could even have some automated facility
> for preparing service directories.
> 
> People can then choose what to use for running a particular
> service, /etc/init.d or linking the service directory into
> /service if the package provides daemontools support.
> 
> I've opened a bug for this (#28294), so what do people
> think of this?
> 
> -- hhg
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Bryan D. Stine]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

But doesn't daemontools itself use an initscript anyway? I suppose you 
just want this to be used in a way similar to how it works with qmail 
and djbdns? It's an interesting idea, but (excuse my ignorance on this) 
I don't really see what positive impact it will have on the system. Feel 
free to insult and enlighten me!

Hallgrimur H. Gunnarsson wrote:

>Hello friends !
>
>I'd like to propose a new USE flag.
>
>On my systems I've added a 'daemontools' USE flag
>as an alternative to the current init.d for
>service management. To be a true metadistribution,
>it doesn't seem fair to let init.d have a monopoly
>on providing service management for packages.
>
>For those who haven't heard of it before, daemontools
>is a process supervisor that can manage services.
>For more information see http://cr.yp.to/daemontools.html
>
>Integration of this functionality into ebuilds is in
>most cases very trivial. Packages that wish to
>provide daemontools USE flag support provide
>a 'run' file, that is copied to a service directory,
>/etc/daemontools/servicename, or something in that
>direction.  We could even have some automated facility
>for preparing service directories.
>
>People can then choose what to use for running a particular
>service, /etc/init.d or linking the service directory into
>/service if the package provides daemontools support.
>
>I've opened a bug for this (#28294), so what do people
>think of this?
>
>-- hhg
>
>
>--
>gentoo-dev@gentoo.org mailing list
>
>
>  
>


[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Hallgrimur H. Gunnarsson]

On 09.09.2003 "Bryan D. Stine" <admin@kentonet.net> wrote:
> But doesn't daemontools itself use an initscript anyway? I suppose you 
> just want this to be used in a way similar to how it works with qmail 
> and djbdns? It's an interesting idea, but (excuse my ignorance on this) 
> I don't really see what positive impact it will have on the system. Feel 
> free to insult and enlighten me!

Daemontools has to be run from somewhere yes, just as init.d is
run through inittab.

Daemontools is currently being executed through an init.d script,
which is not the preferred way to do it. Usually you run it from
inittab.

-- hhg

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Hallgrimur H. Gunnarsson]

Sorry, I forgot to answer the real question :-). There is definitely
a positive impact.

Daemontools is just an alternative to init.d, it has some advantages
over it in my opinion, such as portability, more flexibility with
signals, logging and more. You can read up on some of the advantages
in the http://cr.yp.to/daemontools/faq.html.

Of course, this is a matter of taste. But daemontools is already being
used to supervise some services, such as qmail and djbdns. And since
it's already in use, I think it'd be the right thing to do to implement
some generic mechanism in which services can offer you to use
daemontools to supervise them, i.e. the USE flag.

-- hhg

On 09.09.2003 "Hallgrimur H. Gunnarsson" <hhg@data.is> wrote:
> On 09.09.2003 "Bryan D. Stine" <admin@kentonet.net> wrote:
> > But doesn't daemontools itself use an initscript anyway? I suppose you 
> > just want this to be used in a way similar to how it works with qmail 
> > and djbdns? It's an interesting idea, but (excuse my ignorance on this) 
> > I don't really see what positive impact it will have on the system. Feel 
> > free to insult and enlighten me!
> 
> Daemontools has to be run from somewhere yes, just as init.d is
> run through inittab.
> 
> Daemontools is currently being executed through an init.d script,
> which is not the preferred way to do it. Usually you run it from
> inittab.
> 
> -- hhg
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Bryan D. Stine]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

Personally, when using qmail and djbdns, I found daemontools to be a bit 
of an annoyance. But, as you said, it's purely a matter of taste. I'm 
all about the availability of choice when benefits can result.

I'll leave it up to real Gentoo devs as to whether or not a USE flag 
would be the best choice (can't think of anything better off the top of 
my head), but it certainly seems worth a looksee.

Hallgrimur H. Gunnarsson wrote:

>Sorry, I forgot to answer the real question :-). There is definitely
>a positive impact.
>
>Daemontools is just an alternative to init.d, it has some advantages
>over it in my opinion, such as portability, more flexibility with
>signals, logging and more. You can read up on some of the advantages
>in the http://cr.yp.to/daemontools/faq.html.
>
>Of course, this is a matter of taste. But daemontools is already being
>used to supervise some services, such as qmail and djbdns. And since
>it's already in use, I think it'd be the right thing to do to implement
>some generic mechanism in which services can offer you to use
>daemontools to supervise them, i.e. the USE flag.
>
>-- hhg
>
>On 09.09.2003 "Hallgrimur H. Gunnarsson" <hhg@data.is> wrote:
>  
>
>>On 09.09.2003 "Bryan D. Stine" <admin@kentonet.net> wrote:
>>    
>>
>>>But doesn't daemontools itself use an initscript anyway? I suppose you 
>>>just want this to be used in a way similar to how it works with qmail 
>>>and djbdns? It's an interesting idea, but (excuse my ignorance on this) 
>>>I don't really see what positive impact it will have on the system. Feel 
>>>free to insult and enlighten me!
>>>      
>>>
>>Daemontools has to be run from somewhere yes, just as init.d is
>>run through inittab.
>>
>>Daemontools is currently being executed through an init.d script,
>>which is not the preferred way to do it. Usually you run it from
>>inittab.
>>
>>-- hhg
>>
>>--
>>gentoo-dev@gentoo.org mailing list
>>
>>    
>>
>
>
>  
>


[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Juan Jesus Prieto]

Hi all,

   This is the first time I write to that list and I want to take this 
opportunity to thank everyone for this great distribution.

El Mié 10 Sep 2003 00:24, Bryan D. Stine escribió:
> Personally, when using qmail and djbdns, I found daemontools to be a bit
> of an annoyance. But, as you said, it's purely a matter of taste. I'm
> all about the availability of choice when benefits can result.

   I have been working with daemontools in another distributions (I'm LEAF 
developer) and I agree with you: daemontools is a bit of an annoyance :-P. 
But sometimes is a great help. For example I use 'supervise' to make a bash 
daemon to control the log file size from dansguardian (dansg over embedded 
system) using a pipe file. Thanks to daemontools I have been able to build a 
simple solution :-).

   Sometimes, if the system is not correctly configured, the /var/log 
partition in LEAF may exceed. Then a multicron script review every 15 min 
(programmable) the partitions size and tries to clean the partition to open 
some space, but in that previous situation the internal proxy-cache (squid) 
crash if it try to write its logs in a partition overflowed. If you run squid 
under 'supervise' as 'squid -D -N', you may capture the stderr and stdout 
with multilog and restart the process if it was down.

  You also may use daemontools to avoid some kind of DoS logs-flood.

> I'll leave it up to real Gentoo devs as to whether or not a USE flag
> would be the best choice (can't think of anything better off the top of
> my head), but it certainly seems worth a looksee.

-- 
Juan Jesus Prieto Tapia
jjptapia@eresmas.com

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Martin Lesser]

"Hallgrimur H. Gunnarsson" <hhg@data.is> writes:

> I'd like to propose a new USE flag.
> 
> On my systems I've added a 'daemontools' USE flag
> as an alternative to the current init.d for
> service management. To be a true metadistribution,
> it doesn't seem fair to let init.d have a monopoly
> on providing service management for packages.

I second this idea.

But if I understand http://www.gentoo.org/doc/en/faq.xml#doc_chap8_sect1
correctly former gentoo distris used daemontools so I would like to know
why gentoo switched away from this really good and stable piece of
software.

Martin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Wes Chow]

> But if I understand http://www.gentoo.org/doc/en/faq.xml#doc_chap8_sect1
> correctly former gentoo distris used daemontools so I would like to know
> why gentoo switched away from this really good and stable piece of
> software.

I always thought daemontools sounded nice, but have never tried to
actually use it for system services.  Actually, there is one thing that
I'm not quite sure how it deals with, which is dependencies.  For
example, under the Gentoo init scripts, you can specify that, the
"httpd" service only gets started after the "net" service is up and
running.  Looking over daemontools, I wasn't able to find any obvious
way of doing this.  Is there?

Wes

-- 
http://www.woahnelly.net/~wes/          OpenPGP key = 0xA5CA6644
fingerprint = FDE5 21D8 9D8B 386F 128F  DF52 3F52 D582 A5CA 6644

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Hallgrimur H. Gunnarsson]

On 11.09.2003 Wes Chow <wes@woahnelly.net> wrote:
> 
> I always thought daemontools sounded nice, but have never tried to
> actually use it for system services.  Actually, there is one thing that
> I'm not quite sure how it deals with, which is dependencies.  For
> example, under the Gentoo init scripts, you can specify that, the
> "httpd" service only gets started after the "net" service is up and
> running.  Looking over daemontools, I wasn't able to find any obvious
> way of doing this.  Is there?

No, that'd be implemented in another layer above daemontools itself
(provided that you'd even want to do that with daemontools).
Daemontools is not meant to replace init.d in network initialization,
which isn't a daemon, so you couldn't supervise
it with daemontools. Daemontools is for managing daemons,
starting, stopping, restarting, status, signal delivery. Daemontools
ensures that a daemon will be running, init.d doesnt notice or restart
a service if it suddenly dies, init.d also doesnt offer logging
in the way daemontools can provide it.

Daemontools is already being used by at least qmail and djbdns by
default. By introducing a USE flag we get many advantages:

*) Packages can provide daemontools and init.d support. The user
can choose what to use for managing a service.

*) Packages using daemontools as default now, can provide init.d
support if 'daemontools' is not set.

etc.

I'd also like to point out two additional packages in portage
that might be of use if you're using or planning on checking
out daemontools.

daemontools-man: provides man pages for daemontools.
supervise-scripts: simplified wrappers for managing services in
daemontools.

You can also read up on bug #28294, where alot of discussion
has been going on.

Martin Schlemmer (azarah) has given a green light on this, so
I'll be submitting daemontools-aware modification for ebuilds
during the next days.

-- hhg

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Henti Smith]

On Thu, 11 Sep 2003 16:00:24 +0000
"Hallgrimur H. Gunnarsson" <hhg@data.is> wrote:

> Daemontools is not meant to replace init.d in network initialization,

for a inet.d replacement look at tcpserver .. also by same author.

-- 
Henti Smith
bain@tcsn.co.za
Senior Administrator
The Computer-Smith Networking
http://www.tcsn.co.za

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Hallgrimur H. Gunnarsson]

On 11.09.2003 Henti Smith <bain@tcsn.co.za> wrote:
> On Thu, 11 Sep 2003 16:00:24 +0000
> "Hallgrimur H. Gunnarsson" <hhg@data.is> wrote:
> 
> > Daemontools is not meant to replace init.d in network initialization,
> 
> for a inet.d replacement look at tcpserver .. also by same author

Are you confusing the init.d rc scripts with inetd/xinetd (no inet.d), or
just going off-topic? :-)

Also, tcpserver is part of ucspi-tcp.

-- hhg

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Andrew Gaffney]

Henti Smith wrote:
> On Thu, 11 Sep 2003 16:00:24 +0000
> "Hallgrimur H. Gunnarsson" <hhg@data.is> wrote:
> 
> 
>>Daemontools is not meant to replace init.d in network initialization,
> 
> 
> for a inet.d replacement look at tcpserver .. also by same author.

Different things. init.d is Gentoo's init scripts. inetd is a 
super-server, like xinetd.

-- 
Andrew Gaffney


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Henti Smith]

On Thu, 11 Sep 2003 11:28:35 -0500
Andrew Gaffney <agaffney@technaut.darktalker.net> wrote:

> > for a inet.d replacement look at tcpserver .. also by same author.
> 
> Different things. init.d is Gentoo's init scripts. inetd is a 
> super-server, like xinetd.

apologies, read the mail to quickly

-- 
Henti Smith
bain@tcsn.co.za
Senior Administrator
The Computer-Smith Networking
http://www.tcsn.co.za

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Wes Chow]

> No, that'd be implemented in another layer above daemontools itself
> (provided that you'd even want to do that with daemontools).
> Daemontools is not meant to replace init.d in network initialization,
> which isn't a daemon, so you couldn't supervise
> it with daemontools. Daemontools is for managing daemons,
> starting, stopping, restarting, status, signal delivery.

But, can't daemons have dependencies on other daemons as well?  For
example, nfs depends on portmap.  Many of these daemons might also
depend on the system logger.  It'd be nice to have the logger supervised
*and* started up before any other daemon.

And the implication with this faq entry:
http://cr.yp.to/daemontools/faq/create.html#why is that daemontools is
supposed to mostly replace all these init systems.

At any rate, somebody else mentioned runit, which claims to be
daemontools-like and has dependency support (and a more conventional
license).  "emerge search runit" didn't come up with anything, but maybe
it should get some brain time as an option to daemontools?

And after reading your bug posting, I agree that it would be nice to
have automatically merged run scripts for daemons just in case you want
to use a daemontool-like system.

Wes

-- 
http://www.woahnelly.net/~wes/          OpenPGP key = 0xA5CA6644
fingerprint = FDE5 21D8 9D8B 386F 128F  DF52 3F52 D582 A5CA 6644

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Hallgrimur H. Gunnarsson]

On 11.09.2003 Wes Chow <wes@woahnelly.net> wrote:
> 
> > No, that'd be implemented in another layer above daemontools itself
> > (provided that you'd even want to do that with daemontools).
> > Daemontools is not meant to replace init.d in network initialization,
> > which isn't a daemon, so you couldn't supervise
> > it with daemontools. Daemontools is for managing daemons,
> > starting, stopping, restarting, status, signal delivery.
> 
> But, can't daemons have dependencies on other daemons as well?  For
> example, nfs depends on portmap.  Many of these daemons might also
> depend on the system logger.  It'd be nice to have the logger supervised
> *and* started up before any other daemon.

Yes they can, but as I vaguely said earlier, daemontools support
will only suit a specific group of daemons, i.e. those who're
pretty independant, and there are other qualifications as well,
such as logging to stdout if you want to use the provided
daemontools logging methods, running in foreground, etc.

> 
> And the implication with this faq entry:
> http://cr.yp.to/daemontools/faq/create.html#why is that daemontools is
> supposed to mostly replace all these init systems.

Yap, and it can, but as I said earlier, it'd have to implemented
in another layer above daemontools.

> 
> At any rate, somebody else mentioned runit, which claims to be
> daemontools-like and has dependency support (and a more conventional
> license).  "emerge search runit" didn't come up with anything, but maybe
> it should get some brain time as an option to daemontools?

Yes, runit was written by the same guy (Gerrit Pape) that converted
the html documentation to man pages for daemontools. I've checked
it out, but I havent used it yet. It might be nice to have a 
runit USE flag too, if it works well. However, for the time being
we also need a daemontools USE flag, since there's obviously demand
for it, and there are services using daemontools now (qmail, djbdns).

> 
> And after reading your bug posting, I agree that it would be nice to
> have automatically merged run scripts for daemons just in case you want
> to use a daemontool-like system.

:-)

-- hhg

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Frederick Grim]

So Wes Chow <wes@woahnelly.net> was all like, and shit:
> 
> > No, that'd be implemented in another layer above daemontools itself
> > (provided that you'd even want to do that with daemontools).
> > Daemontools is not meant to replace init.d in network initialization,
> > which isn't a daemon, so you couldn't supervise
> > it with daemontools. Daemontools is for managing daemons,
> > starting, stopping, restarting, status, signal delivery.
> 
> But, can't daemons have dependencies on other daemons as well?  For
> example, nfs depends on portmap.  Many of these daemons might also
> depend on the system logger.  

bernstein has a recommended logging system that can be used in conjuction with netcat and
multitail ( if you have a centralized log server ).  Also most of these daemons can be
configured to log to stderr or stdout.  so a portmap run script may look something like
#!/bin/sh

exec /usr/bin/tcpserver 0 111 /sbin/portmap -d 2>&1

with it's associated log/run script

#!/bin/sh
exec /usr/bin/setuidgid nobody /usr/bin/multilog t s2500000 /var/log/supervise/portmap

which bypasses these dependancies.  I have found, using daemontools that the system logger
is only useful for a few broken daemons that can't be configured to log to stdout. 

So this is sort of an important point.  If runscripts are included will the logging by
default be to the stdout or to syslog? 

> It'd be nice to have the logger supervised
> *and* started up before any other daemon.
> 
> And the implication with this faq entry:
> http://cr.yp.to/daemontools/faq/create.html#why is that daemontools is
> supposed to mostly replace all these init systems.
> 
> At any rate, somebody else mentioned runit, which claims to be
> daemontools-like and has dependency support (and a more conventional
> license).  "emerge search runit" didn't come up with anything, but maybe
> it should get some brain time as an option to daemontools?
> 
> And after reading your bug posting, I agree that it would be nice to
> have automatically merged run scripts for daemons just in case you want
> to use a daemontool-like system.
> 
> Wes
> 
> -- 
> http://www.woahnelly.net/~wes/          OpenPGP key = 0xA5CA6644
> fingerprint = FDE5 21D8 9D8B 386F 128F  DF52 3F52 D582 A5CA 6644
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

-- 
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo
16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Frederick Grim]

So Frederick Grim <fgrim@norby.dyndns.org> was all like, and shit:
> So Wes Chow <wes@woahnelly.net> was all like, and shit:
> > 
> > > No, that'd be implemented in another layer above daemontools itself
> > > (provided that you'd even want to do that with daemontools).
> > > Daemontools is not meant to replace init.d in network initialization,
> > > which isn't a daemon, so you couldn't supervise
> > > it with daemontools. Daemontools is for managing daemons,
> > > starting, stopping, restarting, status, signal delivery.
> > 
> > But, can't daemons have dependencies on other daemons as well?  For
> > example, nfs depends on portmap.  Many of these daemons might also
> > depend on the system logger.

ohh and I just thought of something else. In the run scripts you could probably enforce the
dependencies either by specifically naming the softlinks correctly or using some
combination of svstat and sleep in a loop. So in any case the startup order is maintained.
I can't imagine that would be anymore difficult coding wise then the current system in
init.d .

> 
> bernstein has a recommended logging system that can be used in conjuction with netcat and
> multitail ( if you have a centralized log server ).  Also most of these daemons can be
> configured to log to stderr or stdout.  so a portmap run script may look something like
> #!/bin/sh
> 
> exec /usr/bin/tcpserver 0 111 /sbin/portmap -d 2>&1
> 
> with it's associated log/run script
> 
> #!/bin/sh
> exec /usr/bin/setuidgid nobody /usr/bin/multilog t s2500000 /var/log/supervise/portmap
> 
> which bypasses these dependancies.  I have found, using daemontools that the system logger
> is only useful for a few broken daemons that can't be configured to log to stdout. 
> 
> So this is sort of an important point.  If runscripts are included will the logging by
> default be to the stdout or to syslog? 
> 
> > It'd be nice to have the logger supervised
> > *and* started up before any other daemon.
> > 
> > And the implication with this faq entry:
> > http://cr.yp.to/daemontools/faq/create.html#why is that daemontools is
> > supposed to mostly replace all these init systems.
> > 
> > At any rate, somebody else mentioned runit, which claims to be
> > daemontools-like and has dependency support (and a more conventional
> > license).  "emerge search runit" didn't come up with anything, but maybe
> > it should get some brain time as an option to daemontools?
> > 
> > And after reading your bug posting, I agree that it would be nice to
> > have automatically merged run scripts for daemons just in case you want
> > to use a daemontool-like system.
> > 
> > Wes
> > 
> > -- 
> > http://www.woahnelly.net/~wes/          OpenPGP key = 0xA5CA6644
> > fingerprint = FDE5 21D8 9D8B 386F 128F  DF52 3F52 D582 A5CA 6644
> > 
> > --
> > gentoo-dev@gentoo.org mailing list
> > 
> 
> -- 
> #!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo
> 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

-- 
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo
16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Hallgrimur H. Gunnarsson]

On 11.09.2003 Frederick Grim <fgrim@norby.dyndns.org> wrote:
> #!/bin/sh
> 
> exec /usr/bin/tcpserver 0 111 /sbin/portmap -d 2>&1
> 
> with it's associated log/run script
> 
> #!/bin/sh
> exec /usr/bin/setuidgid nobody /usr/bin/multilog t s2500000
> /var/log/supervise/portmap
> 
> which bypasses these dependancies.  I have found, using daemontools
> that the system logger is only useful for a few broken daemons that
> can't be configured to log to stdout. 
> 
> So this is sort of an important point.  If runscripts are included 
> will the logging by default be to the stdout or to syslog? 

I think it should definitely be stdout by default, even if it were
just to force that support into all packages who wish to provide
daemontools support, so that you dont install a program that claims
to support 'daemontools' but doesnt allow to use another logger than
syslog.

Perhaps we should come up with some method in which 'run' files
are installed?

Should we have a /etc/supervise/packagename or
/etc/daemontools/packagename, or something like that?

- hhg

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: gentoo-dev@gentoo.org

[Hallgrimur H. Gunnarsson]

On 11.09.2003 Frederick Grim <fgrim@norby.dyndns.org> wrote:
> So Hallgrimur H. Gunnarsson <hhg@data.is> was all like, and shit:
> > Perhaps we should come up with some method in which 'run' files
> > are installed?
> > 
> > Should we have a /etc/supervise/packagename or
> > /etc/daemontools/packagename, or something like that?
> 
> I would think so as well as something like /var/log/supervise chowned by nobody.  Dan's
> setup scripts tend to do things like keep the logs in /etc/tiny-dns/log/main but that seems
> wrong.  logs go in /var/log and most people partition with that in mind.

Yap, sounds wise. We could have /var/log/supervise/package/. Owned by
nobody isn't really necessary. Packages can decide for themselves
how to handle permissions for logging. Qmail for example has
qmaill for logging purposes.

-- hhg

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Mark Francis]

I have created bugs 28938, 28940, 28941, 28943 and 28945 to add daemontools support
to the init scripts for samba, xinetd, fcron, cupsd and syslog-ng. Feel free to try
it and see what you think. 

I discuss my approach in bug 28294. To summarise:

1. daemontools is not required but can optionally be used if available.

2. The daemontools service directory for each daemon is located in /var/daemontools

3. This method has flexibility in that a user can choose to start each daemon in
one of 3 different ways. The existing method (usually start-stop-daemon) in an init
script, supervise from an init script, or svscan by creating a link to /var/daemontools/$name
at /service/$name. Running supervise from the init script has the advantages of both
init dependancy support and daemon monitoring.

4. No daemontools USE flag is required using this method.

Mark



Hallgrimur H. Gunnarsson wrote:

>On 11.09.2003 Frederick Grim <fgrim@norby.dyndns.org> wrote:
>  
>
>>#!/bin/sh
>>
>>exec /usr/bin/tcpserver 0 111 /sbin/portmap -d 2>&1
>>
>>with it's associated log/run script
>>
>>#!/bin/sh
>>exec /usr/bin/setuidgid nobody /usr/bin/multilog t s2500000
>>/var/log/supervise/portmap
>>
>>which bypasses these dependancies.  I have found, using daemontools
>>that the system logger is only useful for a few broken daemons that
>>can't be configured to log to stdout. 
>>
>>So this is sort of an important point.  If runscripts are included 
>>will the logging by default be to the stdout or to syslog? 
>>    
>>
>
>I think it should definitely be stdout by default, even if it were
>just to force that support into all packages who wish to provide
>daemontools support, so that you dont install a program that claims
>to support 'daemontools' but doesnt allow to use another logger than
>syslog.
>
>Perhaps we should come up with some method in which 'run' files
>are installed?
>
>Should we have a /etc/supervise/packagename or
>/etc/daemontools/packagename, or something like that?
>
>- hhg
>
>--
>gentoo-dev@gentoo.org mailing list
>
>  
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Petre Rodan]

On Wed, Sep 17, 2003 at 05:00:37PM +1000, Mark Francis wrote:
> I have created bugs 28938, 28940, 28941, 28943 and 28945 to add daemontools 
> support
> to the init scripts for samba, xinetd, fcron, cupsd and syslog-ng. Feel 
> free to try
> it and see what you think. 

Great idea.
 
> I discuss my approach in bug 28294. To summarise:
> 
> 1. daemontools is not required but can optionally be used if available.
> 
> 2. The daemontools service directory for each daemon is located in 
> /var/daemontools

/var/service/ is already being used by sys-apps/supervise-scripts ...

> 
> 3. This method has flexibility in that a user can choose to start each 
> daemon in
> one of 3 different ways. The existing method (usually start-stop-daemon) in 
> an init
> script, supervise from an init script, or svscan by creating a link to 
> /var/daemontools/$name
> at /service/$name. Running supervise from the init script has the 
> advantages of both
> init dependancy support and daemon monitoring.
> 
> 4. No daemontools USE flag is required using this method.
> 
> Mark
> 

bye,
peter
 
> 
> Hallgrimur H. Gunnarsson wrote:
> 
> >On 11.09.2003 Frederick Grim <fgrim@norby.dyndns.org> wrote:
> > 
> >
> >>#!/bin/sh
> >>
> >>exec /usr/bin/tcpserver 0 111 /sbin/portmap -d 2>&1
> >>
> >>with it's associated log/run script
> >>
> >>#!/bin/sh
> >>exec /usr/bin/setuidgid nobody /usr/bin/multilog t s2500000
> >>/var/log/supervise/portmap
> >>
> >>which bypasses these dependancies.  I have found, using daemontools
> >>that the system logger is only useful for a few broken daemons that
> >>can't be configured to log to stdout. 
> >>
> >>So this is sort of an important point.  If runscripts are included 
> >>will the logging by default be to the stdout or to syslog? 
> >>   
> >>
> >
> >I think it should definitely be stdout by default, even if it were
> >just to force that support into all packages who wish to provide
> >daemontools support, so that you dont install a program that claims
> >to support 'daemontools' but doesnt allow to use another logger than
> >syslog.
> >
> >Perhaps we should come up with some method in which 'run' files
> >are installed?
> >
> >Should we have a /etc/supervise/packagename or
> >/etc/daemontools/packagename, or something like that?
> >
> >- hhg
> >
> >--
> >gentoo-dev@gentoo.org mailing list
> >
> > 
> >
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

-- 

Petre Rodan
Senior Network Engineer
GeCAD Software - RAV Division

----------------------------------------------------------------------
Tel/Fax: +40-21-321-7803
Hotline:  +40-21-321-7859

This message is confidential. It may also be privileged or otherwise 
protected by work product immunity or other legal rules. 
If you have received it by mistake please let us know by reply and then 
delete it from your system; you should not copy the message or disclose 
its contents to anyone.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New USE flag 'daemontools' as an alternative to init.d

[Petre Rodan]

On Tue, Sep 09, 2003 at 09:11:12PM +0000, Hallgrimur H. Gunnarsson wrote:
> Hello friends !
> 
> I'd like to propose a new USE flag.
> 
> On my systems I've added a 'daemontools' USE flag
> as an alternative to the current init.d for
> service management. To be a true metadistribution,
> it doesn't seem fair to let init.d have a monopoly
> on providing service management for packages.
> 
> For those who haven't heard of it before, daemontools
> is a process supervisor that can manage services.
> For more information see http://cr.yp.to/daemontools.html
> 
> Integration of this functionality into ebuilds is in
> most cases very trivial. Packages that wish to
> provide daemontools USE flag support provide
> a 'run' file, that is copied to a service directory,
> /etc/daemontools/servicename, or something in that
> direction.  We could even have some automated facility
> for preparing service directories.
> 
> People can then choose what to use for running a particular
> service, /etc/init.d or linking the service directory into
> /service if the package provides daemontools support.
> 
> I've opened a bug for this (#28294), so what do people
> think of this?
> 
> -- hhg
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

I think this is a great idea.

I am currently using daemontools on many machines and I've found that any of the following daemons can very easily be 'supervised':

apache, clockspeed, crond, fcron, cupsd, dictd, ftpd (publicfile), junkbuster, klogd, lircd, mysqld, nmbd, mysqld, rsync, smbd, snmpd, snort, squid, sshd, stunnel, syslogd, thttpd, etc.

some DOS attempts can be circumvented by using this type of software.

bye,
peter

--
Petre Rodan
Senior Network Engineer
GeCAD Software - RAV Division

----------------------------------------------------------------------
Tel/Fax: +40-21-321-7803
Hotline:  +40-21-321-7859

This message is confidential. It may also be privileged or otherwise
protected by work product immunity or other legal rules.
If you have received it by mistake please let us know by reply and then
delete it from your system; you should not copy the message or disclose
its contents to anyone.


--
gentoo-dev@gentoo.org mailing list