I'm really not that clear on why a daemon must lose its controlling
terrminal. What happens if the daemon wouldn't lose its controlling
terminal?


Chad

[ Post a follow-up to this message ]

In article <1186707752.486907.162130@g12g2000prg.googlegroups.com>,
K-mart Cashier <cdalten@gmail.com> wrote:

> I'm really not that clear on why a daemon must lose its controlling
> terrminal. What happens if the daemon wouldn't lose its controlling
> terminal?

That terminal will then not be available to assign to other users.

A daemon is generally defined to be a program that runs in the
background on the system, without any direct user interaction.  So what
does it need a controlling terminal for?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

On Aug 9, 6:34 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <1186707752.486907.162...@g12g2000prg.googlegroups.com>,
>  K-mart Cashier <cdal...@gmail.com> wrote:
> 
>
> That terminal will then not be available to assign to other users.
>
At the risk of sounding like a total moron, are saying that if it had
a controlling terminal, it could assign the terminal to another user?
How? Say I log in as cdalten on ttyp4 and my daemon doesn't lose its
controlling terminal. How could the terminal ttyp4 be assigned if
someone else logged on? I don't see how this is possible.

> A daemon is generally defined to be a program that runs in the
> background on the system, without any direct user interaction.  So what
> does it need a controlling terminal for?
>
This has gone from fuzzy to partially fuzze.

[ Post a follow-up to this message ]

On Aug 9, 6:34 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <1186707752.486907.162...@g12g2000prg.googlegroups.com>,
>  K-mart Cashier <cdal...@gmail.com> wrote:
> 
>
> That terminal will then not be available to assign to other users.
>
> A daemon is generally defined to be a program that runs in the
> background on the system, without any direct user interaction.  So what
> does it need a controlling terminal for?
>

I couldn't find an explanation on why a daemon needed to lose it's
controlling terminal in the section on daemons in the book "Advanced
Programming the Unix Environment" by Stevens and Rago. Maybe I just
wasn't paying enough attention when I was reading the chaper on
daemons.

[ Post a follow-up to this message ]

In article <1186711273.474778.162230@d30g2000prg.googlegroups.com>,
K-mart Cashier <cdalten@gmail.com> wrote:

> On Aug 9, 6:34 pm, Barry Margolin <bar...@alum.mit.edu> wrote: 
>
> I couldn't find an explanation on why a daemon needed to lose it's
> controlling terminal in the section on daemons in the book "Advanced
> programming the Unix Environment" by Stevens and Rago. Maybe I just
> wasn't paying enough attention when I was reading the chaper on
> daemons.

Because then it wouldn't be a daemon!  It would be an ordinary,
interactive application.

It's like asking why a quadriplegic has to lose their legs.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

Barry Margolin <barmar@alum.mit.edu> writes:
> In article <1186711273.474778.162230@d30g2000prg.googlegroups.com>,
>  K-mart Cashier <cdalten@gmail.com> wrote: 
>
> Because then it wouldn't be a daemon!  It would be an ordinary,
> interactive application.
>
> It's like asking why a quadriplegic has to lose their legs.

An important reason that a daemon has to lose the controlling terminal
is that the process group associated with that tty gets signals --
SIGTTIN, SIGTTOU, SIGINT, SIGQUIT, and SIGHUP.  A daemon that
terminates when the user logs out probably won't be that useful.

When a controlling terminal is allocated (that is, when a process
group leader with no controlling terminal successfully opens a device
that's a tty without the O_NOCCTY), then the current process group
becomes the foreground process group and will get signals.

The usual way to daemonize yourself (in the absence of the BSD
daemon() function) is something like this:

if (fork() != 0)
_exit(0);
(void) setsid();
if (fork() != 0)
_exit(0);

The reason for the double fork is that when you're not a process group
leader (that is, when pgid != pid), you can't acquire a new
controlling tty.

--
James Carlson, Solaris Networking              <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

[ Post a follow-up to this message ]

On Aug 9, 9:02 pm, K-mart Cashier <cdal...@gmail.com> wrote:
> I'm really not that clear on why a daemon must lose its controlling
> terrminal. What happens if the daemon wouldn't lose its controlling
> terminal?


Basically so that the process isn't subject to the direct control of
another process.  Each terminal can only have one session leader, and
if a process isn't that session leader it's subject to the control of
the session leader.  In the case of a shell, the shell itself is the
session leader and at any point it can place any group of child
processes in the foreground or the background.  It can change their
process groups, making them subject to group signals sent by the
session leader.  When it exits, it terminates all of its child
processes (like a responsible program does.)

Unless you start a program with exec the shell will remain the session
leader of the terminal, so a daemon must release itself as the
foreground process (i.e. current terminal controller) by forking and
allowing its main process to exit.  Next, it releases itself from the
session by calling setsid.  This creates a new session which the
daemon is the leader of.  This also takes away the controlling
terminal since each session can have only one leader and the shell
already owns the terminal.  This leaves the daemon free of a session
leader and free of a terminal; free to do what it wants.  Regardless
of what happens to the terminal or the shell program, it still runs.
It can open a terminal on its own and retains full control over that
terminal.  If a child wants to take it, it will block until the
session leader gives it access (or returns an error if SIGTOU is
blocked.)  The session leader won't block when requesting access to
its terminal and can change control of the terminal at any time.

As an example, the init program will start several login processes as
daemons.  These processes will be session leaders which control the
terminals you log into when the system starts up.  Session leaders
belong to process 1 (init,) so when you daemonize you pull the process
out of its current place in the process tree and move it to the
highest level.
Kevin Barry

[ Post a follow-up to this message ]

ta0kira@yahoo.com wrote:

> On Aug 9, 9:02 pm, K-mart Cashier <cdal...@gmail.com> wrote: 
<snip>[vbcol=seagreen]
> Unless you start a program with exec the shell will remain the session
> leader of the terminal, so a daemon must release itself as the
<snip>
> Kevin Barry

Thank you, for a great answer!
Please, can you tell what will happen if I start a programm with the `exec'?
Thanks.
Ivan Gotovchits

[ Post a follow-up to this message ]

On 2007-08-20, Ivan Gotovchits <ivan.gotovchits@auriga.ru> wrote: 
><snip> 
>
> Thank you, for a great answer!
> Please, can you tell what will happen if I start a programm with the `exec
'?
> Thanks.
> Ivan Gotovchits

As your shell's manpage will undoubtedly say so, it would be highly
redundant of me to say: "exec will replace the shell process image with
that other program".

--
John Tsiombikas (Nuclear / Mindlapse)
nuclear@siggraph.org
http://nuclear.demoscene.gr/

[ Post a follow-up to this message ]

On Aug 20, 2:42 am, John Tsiombikas <nucl...@siggraph.org> wrote:
> On 2007-08-20, Ivan Gotovchits <ivan.gotovch...@auriga.ru> wrote:
> 
> 
>
> As your shell's manpage will undoubtedly say so, it would be highly
> redundant of me to say: "exec will replace the shell process image with
> that other program".


...and that new process becomes the session leader, and therefore the
new owner of the terminal.
Kevin Barry

[ Post a follow-up to this message ]