daemons, sockets and ssh

Hi,

I am a little bit confused about background processes and controlling
terminals.

I'll explain my problem with an example:

I have a process with uses a file socket to communicate with other
processes which is started at boot with a file in /etc/init.d/progname

Since the daemon/process does not go to the background by itself it is
started as follows:

/usr/bin/progname someoptions &

It works well: it it started when entering the right runlevel and I
can control it with the usual

/etc/init.d/progname start|stop|...

commands.

If I try to execute the very same init script via SSH

ssh root@example.org "/etc/init.d/progname start"

The program is started the init script continues to end but the
program hangs the controlling terminal.

With some debugging using strace on the program it seems that the
problem lies in the socket the program creates but I am pretty
confused on the whole issue.

Any hint?

Many thanks

Matteo

Re: daemons, sockets and ssh

On Wed, 9 Apr 2008 07:18:02 -0700 (PDT), Teo
wrote:

>Since the daemon/process does not go to the background by itself it is
>started as follows:
>
> /usr/bin/progname someoptions &

>The program is started the init script continues to end but the
>program hangs the controlling terminal.

>Any hint?

Just spawning a subshell with & won't cause your program to let go of
the controlling terminal.

Any program that wants to be a daemon must do some unix gymnastics (in
C code) to let go of the controlling terminal.

Or you can write a wrapper in C, and let it call progname. I wrote a
C wrapper to do that, but the program to call is hardcoded. It's just
something I was tinkering with. But if you want to see the code, I
can send it to you, and you can modify it as you like.

Email me if you want it.


--
Webmail for Dialup Users
http://www.isp2dial.com/freeaccounts.html

Re: daemons, sockets and ssh

On Wed, 09 Apr 2008 15:50:54 +0000, www.isp2dial.com wrote:

> On Wed, 9 Apr 2008 07:18:02 -0700 (PDT), Teo
> wrote:
>
>>Since the daemon/process does not go to the background by itself it is
>>started as follows:
>>
>> /usr/bin/progname someoptions &
>
>>The program is started the init script continues to end but the program
>>hangs the controlling terminal.
>
>>Any hint?
>
> Just spawning a subshell with & won't cause your program to let go of
> the controlling terminal.
>
> Any program that wants to be a daemon must do some unix gymnastics (in C
> code) to let go of the controlling terminal.
>
> Or you can write a wrapper in C, and let it call progname. I wrote a C
> wrapper to do that, but the program to call is hardcoded. It's just
> something I was tinkering with. But if you want to see the code, I can
> send it to you, and you can modify it as you like.
>
> Email me if you want it.

One or more of the following should do it:

1) setsid - it's not just a C function anymore, it's also a program on
some systems
2) redirect all your output to a file, EG /dev/null
3) redirect all your input to come from a file, EG /dev/null

Re: daemons, sockets and ssh

On Wed, 09 Apr 2008 18:57:35 GMT, Dan Stromberg
wrote:

>> Any program that wants to be a daemon must do some unix gymnastics (in C
>> code) to let go of the controlling terminal.
>>
>> Or you can write a wrapper in C, and let it call progname. I wrote a C
>> wrapper to do that, but the program to call is hardcoded. It's just
>> something I was tinkering with. But if you want to see the code, I can
>> send it to you, and you can modify it as you like.
>>
>> Email me if you want it.
>
>One or more of the following should do it:
>
>1) setsid - it's not just a C function anymore, it's also a program on
>some systems
>2) redirect all your output to a file, EG /dev/null
>3) redirect all your input to come from a file, EG /dev/null

Once upon a time when I was interested in writing a daemon wrapper, I
read that for completeness, you need to do a fork, a setsid, and then
another fork. Then chdir to / and close ALL files up to _SC_OPEN_MAX.
Then reopen 0, 1, and 2. Then clear the environment and set a default
path and shell.

That's what I coded in my test wrapper. If I ever had time to make it
handle command line arguments, it could be a nice piece of code.


--
Webmail for Dialup Users
http://www.isp2dial.com/freeaccounts.html

Re: daemons, sockets and ssh

On Wed, 09 Apr 2008 20:32:58 +0000, www.isp2dial.com
wrote:

>On Wed, 09 Apr 2008 18:57:35 GMT, Dan Stromberg
> wrote:

>>One or more of the following should do it:
>>
>>1) setsid - it's not just a C function anymore, it's also a program on
>>some systems
>>2) redirect all your output to a file, EG /dev/null
>>3) redirect all your input to come from a file, EG /dev/null

>Once upon a time when I was interested in writing a daemon wrapper, I
>read that for completeness, you need to do a fork, a setsid, and then
>another fork. Then chdir to / and close ALL files up to _SC_OPEN_MAX.
>Then reopen 0, 1, and 2. Then clear the environment and set a default
>path and shell.

That jogged some rusty memory cells, so I looked it up again ...

from man 2 setsid:

A process group leader is a process with process group ID
equal to its PID. In order to be sure that setsid will
succeed, fork and exit, and have the child do setsid().


And from
http://www.developerweb.net/forum/archive/index.php/t-3025.h tml

The double fork() thing is meant to make the process an orphan, in
fact making it a child of the init process (usually PID 1) ...

It should be noted that a fork(2) after a sucessful call to setsid(2)
will also orphan the session and thus ensure the daemon and all it
descendants (unless they create a new session for themselves) can
NEVER attain a controlling terminal.


--
Webmail for Dialup Users
http://www.isp2dial.com/freeaccounts.html

Re: daemons, sockets and ssh

In article
<54a47028-d06a-4c6c-a448-5c2db9d785d0@z38g2000hsc.googlegroups.com>,
Teo wrote:

> Hi,
>
> I am a little bit confused about background processes and controlling
> terminals.
>
> I'll explain my problem with an example:
>
> I have a process with uses a file socket to communicate with other
> processes which is started at boot with a file in /etc/init.d/progname
>
> Since the daemon/process does not go to the background by itself it is
> started as follows:
>
> /usr/bin/progname someoptions &
>
> It works well: it it started when entering the right runlevel and I
> can control it with the usual
>
> /etc/init.d/progname start|stop|...
>
> commands.
>
> If I try to execute the very same init script via SSH
>
> ssh root@example.org "/etc/init.d/progname start"
>
> The program is started the init script continues to end but the
> program hangs the controlling terminal.
>
> With some debugging using strace on the program it seems that the
> problem lies in the socket the program creates but I am pretty
> confused on the whole issue.

Try:

ssh root@example.org "/etc/init.d/progname start &0 2>&1 &"

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

Re: daemons, sockets and ssh

Barry Margolin wrote:

> ssh root@example.org "/etc/init.d/progname start &0 2>&1 &"

Those redirections will make stdout and stderr be open for reading only.
Any attempt to write to them will fail with EBADF.

Use

/dev/null 2>&1

or

<>/dev/null >&0 2>&1

--
Geoff Clare

Re: daemons, sockets and ssh

On Fri, 11 Apr 2008 13:56:45 +0100, Geoff Clare
wrote:

>Barry Margolin wrote:
>
>> ssh root@example.org "/etc/init.d/progname start &0 2>&1 &"
>
>Those redirections will make stdout and stderr be open for reading only.
>Any attempt to write to them will fail with EBADF.
>
>Use
>
> /dev/null 2>&1
>

That makes sense.


>or
>
> <>/dev/null >&0 2>&1


But does it ever make sense to have 0 open for writing, or 1 and 2
open for reading?


--
Webmail for Dialup Users
http://www.isp2dial.com/freeaccounts.html

Re: daemons, sockets and ssh

www.isp2dial.com wrote:

>>Use
>>
>> /dev/null 2>&1
>>
>
> That makes sense.
>
>
>>or
>>
>> <>/dev/null >&0 2>&1
>
>
> But does it ever make sense to have 0 open for writing, or 1 and 2
> open for reading?

It's very common. For example, a terminal session is usually set up by
opening the terminal on fd 0 read/write and then duping it onto 1 and 2.

The "more" utility actually takes advantage of this. If you execute

ls -l | more

on a terminal then "more" can't read its interactive commands (space
for the next page, etc.) from fd 0, so it first tries to read them
from fd 2. It will only resort to opening /dev/tty if fd 2 is
unreadable.

--
Geoff Clare

Re: daemons, sockets and ssh

On Apr 9, 5:50 pm, www.isp2dial.com wrote:
[...]
> Or you can write a wrapper in C, and let it call progname. I wrote a
> C wrapper to do that, but the program to call is hardcoded. It's just
> something I was tinkering with. But if you want to see the code, I
> can send it to you, and you can modify it as you like.
>
> Email me if you want it.

I followed John's advice, asked for the code and he agreed to release
it under the Apache 2.0 license. I did some cleanup, made it a little
bit more flexible and released it at:

https://trac.id.ethz.ch/projects/daemonizer

If you find it useful and try it I would be glad to get complaints/
suggestions/comments/...

https://trac.id.ethz.ch/projects/daemonizer/newticket or
matteo.corti@gmail.com

Thanks again John.

Matteo