FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 09-08-2011, 11:08 AM
Thomas Bächler
 
Default Adopting start-stop-daemon in archlinux

Am 08.09.2011 12:08, schrieb Clemens Fruhwirth:
> If you use Debian, you might have come across start-stop-daemon. It's
> part of the dpkg package and encapsulates all the knowledge, they
> learnt when dealing with starting and stopping daemons. It has plenty
> of features ranging from:
>
> * handling pidfiles more intimately (checking the pid files content,
> verifying that the pid given actually is the executable in question)
> * changing UID/GID
> * chrooting, nice-ing
> * retry starting if daemon dies
> * creating pid files when the process doesn't do it, etc, etc.
>
> curl http://clemens.endorphin.org/start-stop-daemon.c | less
> if you want to have look for yourself. It's a single C file.
>
> To me handling pid files correctly is the biggest win. The paradigm
> used commonly in arch
>
> PID=`pidof -o %PPID /usr/bin/executable`
> [ -z "$PID" ] && /usr/bin/executable
>
> is flawed and does not work reliably as shown here
> https://bugs.archlinux.org/task/17138
>
> I propose to switch to start-stop-daemon and deprecate the method above.
>
> http://clemens.endorphin.org/sshd-start-stop-daemon.diff is an example
> of an rc.d script ported to start-stop-daemon. The paradigm -- to my
> personal taste -- is clean and simple. The diffstat is negative
> LOC-wise.
>
> We could either take the aur/start-stop-daemon packaging which
> references dpkg.tar.gz or include into another core package.
> start-stop-daemon.c is public domain.
> --
> Fruhwirth Clemens http://clemens.endorphin.org

Forwarding to the dev list, in case someone doesn't notice it here. In
principle, I think this is a good idea. I want to hear Tom's opinion
though, as this is closely initscripts-related.
 
Old 09-08-2011, 04:01 PM
Tom Gundersen
 
Default Adopting start-stop-daemon in archlinux

Hi guys,

On Thu, Sep 8, 2011 at 1:08 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 08.09.2011 12:08, schrieb Clemens Fruhwirth:
>> If you use Debian, you might have come across start-stop-daemon. It's
>> part of the dpkg package and encapsulates all the knowledge, they
>> learnt when dealing with starting and stopping daemons. It has plenty
>> of features ranging from:
>>
>> * handling pidfiles more intimately (checking the pid files content,
>> verifying that the pid given actually is the executable in question)
>> * changing UID/GID
>> * chrooting, nice-ing
>> * retry starting if daemon dies
>> * creating pid files when the process doesn't do it, etc, etc.
>>
>> curl http://clemens.endorphin.org/start-stop-daemon.c | less
>> if you want to have look for yourself. It's a single C file.
>>
>> To me handling pid files correctly is the biggest win. The paradigm
>> used commonly in arch
>>
>> PID=`pidof -o %PPID /usr/bin/executable`
>> [ -z "$PID" ] && */usr/bin/executable
>>
>> is flawed and does not work reliably as shown here
>> https://bugs.archlinux.org/task/17138
>>
>> I propose to switch to start-stop-daemon and deprecate the method above.
>>
>> http://clemens.endorphin.org/sshd-start-stop-daemon.diff is an example
>> of an rc.d script ported to start-stop-daemon. The paradigm -- to my
>> personal taste -- is clean and simple. The diffstat is negative
>> LOC-wise.
>>
>> We could either take the aur/start-stop-daemon packaging which
>> references dpkg.tar.gz or include into another core package.
>> start-stop-daemon.c is public domain.

In principle I'm in favor of unifying the handling of these sort of
operations, and I agree with Thomas that it should be done in
initscripts as we already have some helper functions there. I'm not
entirely convinced what the best way to do it is, so I'll just make a
few comments:

I think my preferred approach would be to provide some more
helperfunctions in /etc/rc.d/functions which do the most common
operations of the ones you outlined above. Just by glancing over your
ssh-patch I got the impression that we would be better off supporting
fewer options than start-stop-daemon does, to encourage unified/simple
rc scripts. Take --start as an example, we should probably have a
function that looks something like "start($pidfile,$executable,$args)"
. How we implement these functions would be an internal detail of
initscripts (we could either include start-stop-daemon.c or we could
implement them in bash if it is simple enough).

I think we should discuss each function on a case-by-case basis,
whether or not we want to include it.

Several people mentioned systemd: Yes, it is awesome, and it solves
this problem in a much better way than what we can do. However, it is
not relevant to this discussion, as we should aim to have the best rc
scripts possible, regardless of what happens to systemd.

If someone wants to make any suggestions in terms of patches, they are
very welcome at <arch-projects@archlinux.org>.

Cheers,

Tom
 
Old 09-08-2011, 04:01 PM
Tom Gundersen
 
Default Adopting start-stop-daemon in archlinux

Hi guys,

On Thu, Sep 8, 2011 at 1:08 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 08.09.2011 12:08, schrieb Clemens Fruhwirth:
>> If you use Debian, you might have come across start-stop-daemon. It's
>> part of the dpkg package and encapsulates all the knowledge, they
>> learnt when dealing with starting and stopping daemons. It has plenty
>> of features ranging from:
>>
>> * handling pidfiles more intimately (checking the pid files content,
>> verifying that the pid given actually is the executable in question)
>> * changing UID/GID
>> * chrooting, nice-ing
>> * retry starting if daemon dies
>> * creating pid files when the process doesn't do it, etc, etc.
>>
>> curl http://clemens.endorphin.org/start-stop-daemon.c | less
>> if you want to have look for yourself. It's a single C file.
>>
>> To me handling pid files correctly is the biggest win. The paradigm
>> used commonly in arch
>>
>> PID=`pidof -o %PPID /usr/bin/executable`
>> [ -z "$PID" ] && */usr/bin/executable
>>
>> is flawed and does not work reliably as shown here
>> https://bugs.archlinux.org/task/17138
>>
>> I propose to switch to start-stop-daemon and deprecate the method above.
>>
>> http://clemens.endorphin.org/sshd-start-stop-daemon.diff is an example
>> of an rc.d script ported to start-stop-daemon. The paradigm -- to my
>> personal taste -- is clean and simple. The diffstat is negative
>> LOC-wise.
>>
>> We could either take the aur/start-stop-daemon packaging which
>> references dpkg.tar.gz or include into another core package.
>> start-stop-daemon.c is public domain.

In principle I'm in favor of unifying the handling of these sort of
operations, and I agree with Thomas that it should be done in
initscripts as we already have some helper functions there. I'm not
entirely convinced what the best way to do it is, so I'll just make a
few comments:

I think my preferred approach would be to provide some more
helperfunctions in /etc/rc.d/functions which do the most common
operations of the ones you outlined above. Just by glancing over your
ssh-patch I got the impression that we would be better off supporting
fewer options than start-stop-daemon does, to encourage unified/simple
rc scripts. Take --start as an example, we should probably have a
function that looks something like "start($pidfile,$executable,$args)"
. How we implement these functions would be an internal detail of
initscripts (we could either include start-stop-daemon.c or we could
implement them in bash if it is simple enough).

I think we should discuss each function on a case-by-case basis,
whether or not we want to include it.

Several people mentioned systemd: Yes, it is awesome, and it solves
this problem in a much better way than what we can do. However, it is
not relevant to this discussion, as we should aim to have the best rc
scripts possible, regardless of what happens to systemd.

If someone wants to make any suggestions in terms of patches, they are
very welcome at <arch-projects@archlinux.org>.

Cheers,

Tom
 
Old 09-08-2011, 04:50 PM
Tom Gundersen
 
Default Adopting start-stop-daemon in archlinux

On Thu, Sep 8, 2011 at 6:15 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 08.09.2011 18:01, schrieb Tom Gundersen:
>> I think my preferred approach would be to provide some more
>> helperfunctions in /etc/rc.d/functions which do the most common
>> operations of the ones you outlined above. Just by glancing over your
>> ssh-patch I got the impression that we would be better off supporting
>> fewer options than start-stop-daemon does, to encourage unified/simple
>> rc scripts. Take --start as an example, we should probably have a
>> function that looks something like "start($pidfile,$executable,$args)"
>
> Agreed.
>
>> . How we implement these functions would be an internal detail of
>> initscripts (we could either include start-stop-daemon.c or we could
>> implement them in bash if it is simple enough).
>
> Clemens has a point here: Debian already sorted out all the kinks and
> quirks of this topic, and implemented the solution in
> start-stop-daemon.c. Instead of slowly converging towards their result
> (remaining buggy on the way), we would benefit from their work if our
> new helpers in rc.d/functions would simply call start-stop-daemon.

Sure, I'd be happy with including start-stop-daemon in initscripts. I
don't want to just copy the C file though (like we did with minlog),
but pull the sources from whatever upstream is. And I think it makes
sense to keep it internal and not expose it to rc scripts as is (just
so we still have some control on what goes into our rc scripts),
unless someone can successfully argue that it is all awesome.

-t
 
Old 09-08-2011, 04:50 PM
Tom Gundersen
 
Default Adopting start-stop-daemon in archlinux

On Thu, Sep 8, 2011 at 6:15 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 08.09.2011 18:01, schrieb Tom Gundersen:
>> I think my preferred approach would be to provide some more
>> helperfunctions in /etc/rc.d/functions which do the most common
>> operations of the ones you outlined above. Just by glancing over your
>> ssh-patch I got the impression that we would be better off supporting
>> fewer options than start-stop-daemon does, to encourage unified/simple
>> rc scripts. Take --start as an example, we should probably have a
>> function that looks something like "start($pidfile,$executable,$args)"
>
> Agreed.
>
>> . How we implement these functions would be an internal detail of
>> initscripts (we could either include start-stop-daemon.c or we could
>> implement them in bash if it is simple enough).
>
> Clemens has a point here: Debian already sorted out all the kinks and
> quirks of this topic, and implemented the solution in
> start-stop-daemon.c. Instead of slowly converging towards their result
> (remaining buggy on the way), we would benefit from their work if our
> new helpers in rc.d/functions would simply call start-stop-daemon.

Sure, I'd be happy with including start-stop-daemon in initscripts. I
don't want to just copy the C file though (like we did with minlog),
but pull the sources from whatever upstream is. And I think it makes
sense to keep it internal and not expose it to rc scripts as is (just
so we still have some control on what goes into our rc scripts),
unless someone can successfully argue that it is all awesome.

-t
 

Thread Tools




All times are GMT. The time now is 10:15 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org