How come I can't re-acquire the controlling terminal here - Unix

This is a discussion on How come I can't re-acquire the controlling terminal here - Unix ; [cdalten@localhost oakland]$ more reterm.c #include #include #include #include void reterm(void) { pid_t pid; if((pid = fork()) fprintf(stderr, "can't fork\n"); exit(1); } if(pid !=0) exit(1); if(setsid() fprintf(stderr, "setsid error\n"); } } int main(void) { int fd; reterm(); if((fd = open("/dev/null", O_RDONLY ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: How come I can't re-acquire the controlling terminal here

  1. How come I can't re-acquire the controlling terminal here

    [cdalten@localhost oakland]$ more reterm.c
    #include
    #include
    #include
    #include

    void reterm(void)
    {
    pid_t pid;
    if((pid = fork()) < 0) {
    fprintf(stderr, "can't fork\n");
    exit(1);
    }

    if(pid !=0)
    exit(1);

    if(setsid() < 0) {
    fprintf(stderr, "setsid error\n");
    }
    }

    int main(void)
    {

    int fd;

    reterm();

    if((fd = open("/dev/null", O_RDONLY | O_NOCTTY)) < 0) {
    fprintf(stderr, "can't open tty\n");
    exit(1);
    }

    sleep(5000);
    close(fd);

    return 0;
    }
    [cdalten@localhost oakland]$ gcc -Wall reterm.c -o reterm
    [cdalten@localhost oakland]$ ./reterm
    [cdalten@localhost oakland]$ ps waux | grep reterm
    cdalten 25021 0.0 0.0 1484 156 ? Ss 17:36 0:00 ./
    reterm
    cdalten 25031 0.0 0.1 3880 676 pts/3 R+ 17:36 0:00 grep
    reterm
    [cdalten@localhost oakland]$


  2. Re: How come I can't re-acquire the controlling terminal here

    On Aug 12, 2:46*am, K-mart Cashier wrote:
    > [cdalten@localhost oakland]$ more reterm.c
    > [C code]


    What is your question, exactly? Your program seems to behave just
    fine. Did you expect two processes? The child exits because of this
    line:
    if(pid !=0) exit(1);

  3. Re: How come I can't re-acquire the controlling terminal here

    Sjoerd writes:
    >On Aug 12, 2:46=A0am, K-mart Cashier wrote:
    >> [cdalten@localhost oakland]$ more reterm.c
    >> [C code]

    >
    >What is your question, exactly? Your program seems to behave just
    >fine. Did you expect two processes? The child exits because of this
    >line:
    >if(pid !=3D0) exit(1);


    Plus he explicitly disassociated the child from the controlling
    terminal by opening /dev/null (Note that O_NOCTTY has no effect on
    /dev/null) for stdin, stdout and stderr, then calling setsid(2)
    to create a new session. ps -j would have shown the session/process
    group relationships. A new session with no controlling terminal
    was created, exactly as the code requested.

    scott

  4. Re: How come I can't re-acquire the controlling terminal here

    On Aug 12, 10:09 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
    > Sjoerd writes:
    > >On Aug 12, 2:46=A0am, K-mart Cashier wrote:
    > >> [cdalten@localhost oakland]$ more reterm.c
    > >> [C code]

    >
    > >What is your question, exactly? Your program seems to behave just
    > >fine. Did you expect two processes? The child exits because of this
    > >line:
    > >if(pid !=3D0) exit(1);

    >
    > Plus he explicitly disassociated the child from the controlling
    > terminal by opening /dev/null (Note that O_NOCTTY has no effect on
    > /dev/null) for stdin, stdout and stderr, then calling setsid(2)
    > to create a new session. ps -j would have shown the session/process
    > group relationships. A new session with no controlling terminal
    > was created, exactly as the code requested.



    How would I re-acquire it then?


  5. Re: How come I can't re-acquire the controlling terminal here

    K-mart Cashier writes:
    >On Aug 12, 10:09 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
    >> Sjoerd writes:
    >> >On Aug 12, 2:46=A0am, K-mart Cashier wrote:
    >> >> [cdalten@localhost oakland]$ more reterm.c
    >> >> [C code]

    >>
    >> >What is your question, exactly? Your program seems to behave just
    >> >fine. Did you expect two processes? The child exits because of this
    >> >line:
    >> >if(pid !=3D0) exit(1);

    >>
    >> Plus he explicitly disassociated the child from the controlling
    >> terminal by opening /dev/null (Note that O_NOCTTY has no effect on
    >> /dev/null) for stdin, stdout and stderr, then calling setsid(2)
    >> to create a new session. ps -j would have shown the session/process
    >> group relationships. A new session with no controlling terminal
    >> was created, exactly as the code requested.

    >
    >
    >How would I re-acquire it then?
    >


    use the ioctl TIOCSPGRP to set the process group of the controlling terminal
    to the value of getpgid(2) of the child. TIOCSPGRP ioctl targets a
    filedescriptor of a terminal device (serial, console, pseudo).

    IIRC, if you open a terminal device without O_NOCTTY, it will
    become the controlling terminal for the process group by default.

    Feel free to examine the built-in 'fg' and 'bg' commands of any
    shell shource code (e.g. bash or ksh).

    scott

    Dig up the following for a good description of session management.

    Author: Tim Williams
    Title: Session Management in System V Release 4
    Pages: 365-375
    Publisher: USENIX
    Proceedings: USENIX Conference Proceedings
    Date: Winter 1989
    Location: San Diego, CA
    Institution: AT&T Bell Laboratories, Summit

  6. Re: How come I can't re-acquire the controlling terminal here

    On Aug 13, 11:11 am, sc...@slp53.sl.home (Scott Lurndal) wrote:

    > use the ioctl TIOCSPGRP to set the process group of the controlling terminal
    > to the value of getpgid(2) of the child. TIOCSPGRP ioctl targets a
    > filedescriptor of a terminal device (serial, console, pseudo).


    'tcsetpgrp' would be more appropriate since it's standard POSIX,
    whereas ioctls are highly system-dependent (at least if I understand
    correctly that you're assuming the operation is to "foreground" the
    process again.) This *would* cause a block pending the session
    leader's release of the terminal to the requesting process, *but*
    because 'setsid' is called the process is in a different session, and
    therefore can't be given control of the terminal. Any given terminal
    can only have one session whose processes possess that terminal as
    their controlling terminal; one establishes a new session to gain
    independence from its previous session leader.

    On Aug 12, 3:53 am, Sjoerd wrote:

    > What is your question, exactly? Your program seems to behave just
    > fine. Did you expect two processes? The child exits because of this
    > line:
    > if(pid !=0) exit(1);


    This looks like some sort of partial-effort daemonization, but it's
    probably not meant that way.

    To OP: 'setsid' is obviously a mistake if you want to keep using the
    terminal from which you ran your program. You might be looking for
    'setpgid' instead, in which case you'd request "foregrounding" with
    'tcsetpgrp'.
    Kevin P. Barry

+ Reply to Thread