Здравствуйте, Kemm, Вы писали:

K>Здравствуйте, Dair, Вы писали:

D>>то искать в сорцах fork()/fork() (два раза должен fork делаться)

K>Кому это он должен?

From Unix Programming FAQ:

1.7 How do I get my program to act like a daemon?
=================================================

A "daemon" process is usually defined as a background process that does not
belong to a terminal session. Many system services are performed by
daemons; network services, printing etc.

Simply invoking a program in the background isn't really adequate for these
long-running programs; that does not correctly detach the process from the
terminal session that started it. Also, the conventional way of starting
daemons is simply to issue the command manually or from an rc script; the
daemon is expected to put *itself* into the background.

Here are the steps to become a daemon:

1. `fork()' so the parent can exit, this returns control to the command
line or shell invoking your program. This step is required so that
the new process is guaranteed not to be a process group leader. The
next step, `setsid()', fails if you're a process group leader.

2. `setsid()' to become a process group and session group leader. Since a
controlling terminal is associated with a session, and this new
session has not yet acquired a controlling terminal our process now
has no controlling terminal, which is a Good Thing for daemons.

3. `fork()' again so the parent, (the session group leader), can exit.
This means that we, as a non-session group leader, can never regain a
controlling terminal.

4. `chdir("/")' to ensure that our process doesn't keep any directory in
use. Failure to do this could make it so that an administrator
couldn't unmount a filesystem, because it was our current directory.

[Equivalently, we could change to any directory containing files
important to the daemon's operation.]

5. `umask(0)' so that we have complete control over the permissions of
anything we write. We don't know what umask we may have inherited.

[This step is optional]

6. `close()' fds 0, 1, and 2. This releases the standard in, out, and
error we inherited from our parent process. We have no way of knowing
where these fds might have been redirected to. Note that many daemons
use `sysconf()' to determine the limit `_SC_OPEN_MAX'. `_SC_OPEN_MAX'
tells you the maximun open files/process. Then in a loop, the daemon
can close all possible file descriptors. You have to decide if you
need to do this or not. If you think that there might be
file-descriptors open you should close them, since there's a limit on
number of concurrent file descriptors.

7. Establish new open descriptors for stdin, stdout and stderr. Even if
you don't plan to use them, it is still a good idea to have them open.
The precise handling of these is a matter of taste; if you have a
logfile, for example, you might wish to open it as stdout or stderr,
and open `/dev/null' as stdin; alternatively, you could open
`/dev/console' as stderr and/or stdout, and `/dev/null' as stdin, or
any other combination that makes sense for your particular daemon.

Almost none of this is necessary (or advisable) if your daemon is being
started by `inetd'. In that case, stdin, stdout and stderr are all set up
for you to refer to the network connection, and the `fork()'s and session
manipulation should *not* be done (to avoid confusing `inetd'). Only the
`chdir()' and `umask()' steps remain as useful.