deamonizing a program in Unix

Hi all
I have query regarding deamonizing programs in unix.

Usually we do a close of all file descriptors in a loop for
deamonizing. Is this correct?

What if some backend(such as NIS) has cached an file descriptor for
performance issue because of function call before we do deamonizing and
after that during deamonizing since we close all the file descriptors
we are closing the file descriptor opened by the backend also. Is this
correct behaviour of a deamoonizing programs?

Also where can i get the source of daemon() function call?
Any pointers would be helpful

Thanks
Pappan

On Tue, 4 Jan 2005, Pappan wrote:

> Usually we do a close of all file descriptors in a loop for
> deamonizing. Is this correct?

Yep.  Well, you close all the file descriptors you're not using,
which isn't necessarily ALL of them...

> What if some backend(such as NIS) has cached an file descriptor for
> performance issue because of function call before we do deamonizing and
> after that during deamonizing since we close all the file descriptors
> we are closing the file descriptor opened by the backend also. Is this

???  How does one program using a file descriptor affect how you use
it in another?

> Also where can i get the source of daemon() function call?
> Any pointers would be helpful

The example source code for my book, Solaris Systems Programming,
contains a suitable function.  You can find the source code (and
much more) from www.rite-group.com/rich/ssp.

HTH,

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"

.  *   * . * .* .
.   *   .   .*
President,                                          * .  . /\ ( .  . *
Rite Online Inc.                                     . .  / .\   . * .
.*.  / *  \  . .
. /*   o \     .
Voice: +1 (250) 979-1638                            *   '''||'''   .
URL: http://www.rite-online.net                     ******************

"Pappan" <padmanabhanp@fastmail.fm> writes:

> I have query regarding deamonizing programs in unix.
>
> Usually we do a close of all file descriptors in a loop for
> deamonizing. Is this correct?

It might be. Depends on your requirements. For example, a daemon that
spawns other programs would probably want to leave descriptors 0, 1
and 2 open, but pointing to /dev/null.

> What if some backend(such as NIS) has cached an file descriptor for
> performance issue because of function call before we do deamonizing
> and after that during deamonizing since we close all the file
> descriptors we are closing the file descriptor opened by the backend
> also. Is this correct behaviour of a deamoonizing programs?

I didn't understand this. Can you rephrase?

> Also where can i get the source of daemon() function call?
> Any pointers would be helpful

You can get the source code in Stevens' "Advanced Programming the UNIX
Environment" at http://www.kohala.com/start/apue.html. It has a daemon
function in it. Also see

http://www.faqs.org/faqs/unix-faq/programmer/faq/

Look for question 1.7 and the example section at the end.

Joe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pappan wrote:
> Hi all
> I have query regarding deamonizing programs in unix.
>
> Usually we do a close of all file descriptors in a loop for
> deamonizing. Is this correct?

Usually, but not always. Certainly, you normally want to close and
discard the controlling terminal, and you usually want to close any
'unused' file descriptors (i.e. descriptors that might have been left
open by the process that exec'ed your daemon), but closing any other
descriptors is something that you do if you want or need to, not because
you have to.

> What if some backend(such as NIS) has cached an file descriptor for
> performance issue because of function call before we do deamonizing and
> after that during deamonizing since we close all the file descriptors
> we are closing the file descriptor opened by the backend also. Is this
> correct behaviour of a deamoonizing programs?

I'm not sure I understand your scenario here. Could you explain it in
simpler terms? FWIW, if you suspect that a descriptor has been cached,
and that closing the descriptor will cause problems, you don't /have/ to
close the descriptor.

> Also where can i get the source of daemon() function call?
> Any pointers would be helpful

You can take a look at this helpfull page...
http://www.enderunix.org/docs/eng/daemon.php

- --

Lew Pitcher, IT Consultant, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

 iD8DBQFB2uPKagVFX4UWr64RApDJAJ9HWamZrSCt
uNznrK9ErE1ukbb34gCg8XBj
ljlZFAylWWidFUwSvFGN+O4=
=xnZs
-----END PGP SIGNATURE-----

<joe@invalid.address> wrote in message
news:m3sm5hvxco.fsf@invalid.address...
> "Pappan" <padmanabhanp@fastmail.fm> writes: 
>
> It might be. Depends on your requirements. For example, a daemon that
> spawns other programs would probably want to leave descriptors 0, 1
> and 2 open, but pointing to /dev/null.

I'd say it's not a bad idea to do this even in a daemon the doesn't spawn
other programs: at least any spurious output goes to the bit bucket instead
of possibly ending up somewhere you didn't want it to.
 
>
> I didn't understand this. Can you rephrase?

I think Pappan was thinking this: suppose you link your application with a
library, and that library obtains a descriptor (perhaps for a socket) when
you first call into it, but - intentionally - doesn't close it. This may be
done so that subsequent calls are faster.

Clearly, closing that (unknown) descriptor could have "interesting" effects,
particularly if the descriptor is reused.

The way I see it, you can't usually be sure whether or not some library has
deliberately left a descriptor open as part of its internal operation, but
if it has, bad things may happen, so it's usually unwise to close "random"
descriptors.

Alex

"Alex Fraser" <me@privacy.net> wrote in message
news:340999F40h55nU1@individual.net...
[snip]
> The way I see it, you can't usually be sure whether or not some library
> has deliberately left a descriptor open as part of its internal
> operation, but if it has,

In case it isn't obvious, I meant "but if it has, and you close it"

> bad things may happen, so it's usually unwise to close "random"
> descriptors.

Alex

On Tue, 4 Jan 2005, Alex Fraser wrote:

> I think Pappan was thinking this: suppose you link your application with a
> library, and that library obtains a descriptor (perhaps for a socket) when
> you first call into it, but - intentionally - doesn't close it. This may b
e
> done so that subsequent calls are faster.
>
> Clearly, closing that (unknown) descriptor could have "interesting" effect
s,
> particularly if the descriptor is reused.
>
> The way I see it, you can't usually be sure whether or not some library ha
s
> deliberately left a descriptor open as part of its internal operation, but
> if it has, bad things may happen, so it's usually unwise to close "random"
> descriptors.

A fair point, but given that daemonisation (usually) happens very early in
the lifetime of a (long-lived) process, a moot one.  The process should beco
me
a daemon first, before calling other stuff that might have the side effects
you mention.

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"

.  *   * . * .* .
.   *   .   .*
President,                                          * .  . /\ ( .  . *
Rite Online Inc.                                     . .  / .\   . * .
.*.  / *  \  . .
. /*   o \     .
Voice: +1 (250) 979-1638                            *   '''||'''   .
URL: http://www.rite-online.net                     ******************

Rich Teer wrote:
> On Tue, 4 Jan 2005, Alex Fraser wrote:
>
> 
>
>
> A fair point, but given that daemonisation (usually) happens very early in
> the lifetime of a (long-lived) process, a moot one.  The process should be
come
> a daemon first, before calling other stuff that might have the side effect
s
> you mention.
>

I am currently working on patches for Solaris 8 and 9 to fix a bug
due to the (undocumented) use of a file descriptor by the Netscape
security code (NSS) which is used by LDAP. Daemons sometimes try to
initialize things before daemonizing so that errors can be reported
when they start up. In the case of the LDAP backend to the name
service switch, any name service call at all before daemonizing
resulted in this file descriptor being opened, and then being closed
when the process daemonized, resulting in subsequent errors in the
LDAP calls. There are two ways to deal with this kind of thing in
a library. One is to document the usage of the the file descriptor,
and the other is to test if the descriptor is still used and pointing
where you expect it, and to reinit if it is not. The NSS code did
neither.

--
blu

I voted electronically...I think.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

Rich Teer <rich.teer@rite-group.com> writes:

> On Tue, 4 Jan 2005, Alex Fraser wrote:
> 
>
> A fair point, but given that daemonisation (usually) happens very
> early in the lifetime of a (long-lived) process, a moot one.  The
> process should become a daemon first, before calling other stuff
> that might have the side effects you mention.

It might be desirable to do some initial setup before daemonizing, so
if something goes wrong, it can be easily reported.  Many servers
attempt to bind() a socket before becoming a deamon, and exit with an
error code on failure.

--
Måns Rullgård
mru@inprovide.com

On Tue, 4 Jan 2005, Richard Kettlewell wrote:

> Why?  It's not that they can do any harm, and it's sometimes useful to

File descriptors are a finite resource, so they should be manage
accordingly.

> be able to pass file descriptors down to programs executed by the

Yes, but how often would one want a daemon to pass on a file descriptor
IT gets from its parent?  Not also the word "usually", which implies
there might be circumstances under which closing the descriptors is
not a good idea.  But generally, it is the correct thing to do.

> Some bit of the C library called before you daemonize might have
> opened a file descriptor for its own purposes.  If you close it,
> library functions might mysteriously fail later.

Agreed; this is one of those circumstances...  :-)

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"

.  *   * . * .* .
.   *   .   .*
President,                                          * .  . /\ ( .  . *
Rite Online Inc.                                     . .  / .\   . * .
.*.  / *  \  . .
. /*   o \     .
Voice: +1 (250) 979-1638                            *   '''||'''   .
URL: http://www.rite-online.net                     ******************