Prev: lang/perl5.12 segfault (amd64 - 8-STABLE)
Next: Port installing localized manual pages.
From: Doug Barton on 20 Jul 2010 18:38
On Tue, 20 Jul 2010, Greg Larkin wrote:

> Ed Schouten wrote:
>> Hello port maintainers,
>>
>> I think I'd better send an email about this to ports@, because I've seen
>> it in various places and it is getting a bit tiresome to mail all port
>> authors individually.

Unfortunately not all port maintainers follow this list, so you're not
off the hook yet. :) I did a quick and dirty grep for this problem and
it looks like it affects about 76 ports, so not an overwhelming number,
but not a quick afternoon's work either.

>> I've seen various cases in the past where people write rc scripts that
>> do the following:
>>
>> command="/usr/local/bin/dog"
>> command_args="--bark > /dev/null 2>&1 &"
>>
>> So in this case `dog --bark' doesn't daemonize itself, so the & is
>> sufficient here, right? Well, it is not. :-)

Thanks for your excellent analysis of this problem, it's very useful
information.

>> So how can this be solved? We already have a tool in base called
>> daemon(8). It is simply a wrapper around daemon(3) (which calls
>> setsid(2), which you can use to daemonize processes. So the next time
>> you write an rc script and need to daemonize something which cannot do
>> it by itself, please think of the kittens. ;-)
>>
>> [ CCing this to rc@. Maybe we should add some kind of built-in
>> functionality to call daemon(8)? ]

In theory, yes. Currently daemon(8) is located in /usr/sbin which could
be problematic for people doing diskless, but in practice I don't know
of any ports rc.d scripts that start so early that this would be a
problem. If it turns out that it is, we can always move it to /sbin.

> Anyway, here are some examples for daemonizing processes that don't
> already have support for doing it themselves:
>
> Daemonizing an executable without internal daemon support:
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/nullmailer/files/nullmailer.in?rev=1.3;content-type=text%2Fplain
>
> Daemonizing a Python script:
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/viewvc/files/viewvc.in?rev=1.4;content-type=text%2Fplain
>
> I would love to see direct support for these use cases in /etc/rc.subr,
> and am interested in working with someone to add it.

Your first example looks right, I don't know enough about python to
comment on the second. There is also
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/90163 which has some
insight into this. I previously closed that PR, but now it may be time
to revisit this problem.

I heartily encourage you to go forward if you're interested in patching
rc.subr to take care of this. However, there will have to be a ramp-up
period since even if you fix it today, you have about 3 years before you
can guarantee that users on all supported versions of FreeBSD have the
code in rc.subr (which is one of the unstated reasons that I closed the
PR mentioned above).

Here is my perspective on the project:
1. Document the issue in
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html
and give examples of how to do it properly.
2. Contact authors of existing ports that have this issue, and point
them to the documentation. Offer help to fix it.
3. Take a page from pgolluci's book and file PRs with fixes for those
who don't respond in a timely manner, then use the "maintainer timeout"
facility to finish the fixes.
4. After 1., but perhaps in parallel with 2. and 3.; develop a patch for
rc.subr to handle this, perhaps starting with the simple cases. The
patch should include a signaling mechanism so that a port rc.d script
can do something equivalent to:
if [ $rc_subr_with_daemon_fix ]; then
do it the easy way
else
do it the hard way
fi
5. Once there is a new mechanism, repeat the steps in 1-3. :)
6. In 3-4 years, remove the crutches and mandate use of the new
mechanism.

One could also argue that documentation and education are the right
answers, and that patching rc.subr is not necessary. Personally I'm
sympathetic to that line of reasoning, but I'd never want to discourage
someone from improving rc.subr.

If you, or anyone are interested in pursuing any part of this then I'm
happy to help review patches, make suggestions, etc. but I am not going
to be able to own the project, I don't have the time. I would suggest
that starting a new thread on -rc would be the right way to move
forward.


hth,

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Greg Larkin on 20 Jul 2010 19:16
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doug Barton wrote:
> On Tue, 20 Jul 2010, Greg Larkin wrote:
[...]
>> Anyway, here are some examples for daemonizing processes that don't
>> already have support for doing it themselves:
>>
>> Daemonizing an executable without internal daemon support:
>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/nullmailer/files/nullmailer.in?rev=1.3;content-type=text%2Fplain
>>
>>
>> Daemonizing a Python script:
>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/viewvc/files/viewvc.in?rev=1.4;content-type=text%2Fplain
>>
>>
>> I would love to see direct support for these use cases in /etc/rc.subr,
>> and am interested in working with someone to add it.
>
> Your first example looks right, I don't know enough about python to
> comment on the second. There is also
> http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/90163 which has some
> insight into this. I previously closed that PR, but now it may be time
> to revisit this problem.
>
> I heartily encourage you to go forward if you're interested in patching
> rc.subr to take care of this. However, there will have to be a ramp-up
> period since even if you fix it today, you have about 3 years before you
> can guarantee that users on all supported versions of FreeBSD have the
> code in rc.subr (which is one of the unstated reasons that I closed the
> PR mentioned above).
>
> Here is my perspective on the project:
> 1. Document the issue in
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html
> and give examples of how to do it properly.
> 2. Contact authors of existing ports that have this issue, and point
> them to the documentation. Offer help to fix it.
> 3. Take a page from pgolluci's book and file PRs with fixes for those
> who don't respond in a timely manner, then use the "maintainer timeout"
> facility to finish the fixes.
> 4. After 1., but perhaps in parallel with 2. and 3.; develop a patch for
> rc.subr to handle this, perhaps starting with the simple cases. The
> patch should include a signaling mechanism so that a port rc.d script
> can do something equivalent to:
> if [ $rc_subr_with_daemon_fix ]; then
> do it the easy way
> else
> do it the hard way
> fi
> 5. Once there is a new mechanism, repeat the steps in 1-3. :)
> 6. In 3-4 years, remove the crutches and mandate use of the new mechanism.
>
> One could also argue that documentation and education are the right
> answers, and that patching rc.subr is not necessary. Personally I'm
> sympathetic to that line of reasoning, but I'd never want to discourage
> someone from improving rc.subr.
>
> If you, or anyone are interested in pursuing any part of this then I'm
> happy to help review patches, make suggestions, etc. but I am not going
> to be able to own the project, I don't have the time. I would suggest
> that starting a new thread on -rc would be the right way to move forward.
>
>
> hth,
>
> Doug
>

Hi Doug,

Thank you for the useful background information and ideas about how to
proceed forward. I'll put this task on my list (hah!) and see how much
progress I can make.

Cheers,
Greg
- --
Greg Larkin

http://www.FreeBSD.org/ - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/sourcehosting/ - Follow me, follow you
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFMRi4x0sRouByUApARAlFzAKCE6mkF0zqxwIdR5vRYjCGpub0pFgCeNBl/
SFS3p4Mkl754eone1H8NmL4=
=8kT2
-----END PGP SIGNATURE-----

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Doug Barton on 20 Jul 2010 19:18
On Tue, 20 Jul 2010, Greg Larkin wrote:

> Hi Doug,
>
> Thank you for the useful background information and ideas about how to
> proceed forward. I'll put this task on my list (hah!) and see how much
> progress I can make.

Glad to help! :)

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Jos Backus on 20 Jul 2010 19:46
Fwiw, I would much prefer FreeBSD ship with some sort of process supervisor
a la daemontools.

Jos
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Doug Barton on 20 Jul 2010 20:25
On 07/20/10 16:46, Jos Backus wrote:
> Fwiw, I would much prefer FreeBSD ship with some sort of process supervisor
> a la daemontools.

That's an interesting idea, but until we have someone willing to
actually do that work we need to deal with what we have.


Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: lang/perl5.12 segfault (amd64 - 8-STABLE)
Next: Port installing localized manual pages.