Re: daemontools control over sophie not working any more since release 3.04

This is a multi-part message in MIME format.
--===============0351171339==
Content-Type: multipart/alternative;
	boundary="------------020207000508000905000609"

This is a multi-part message in MIME format.
--------------020207000508000905000609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by dns1.vanja.com id j8QBPtgk012646

Scott,

thank You for the fast reply, let me try to explain the problem we have.
So far we prefered using bernstein=B4s daemontools instead of the usual=20
init.d start/stop scripts to control the sophie daemon process.
The use of daemontools garanteed reliable restarts of the sophie process=20
if it unexpectedly died. We have made good experiences with daemontools=20
so far.

Now with sophie version 3.04, if I send signals to sophie (SIGTERM /=20
SIGHUP) by using the daemontools "svc" command, theses signals go to the=20
sophie main process and not to the subprocess. I don=B4t have deeper=20
knowledge about the way daemontools work, but for me it seems that svc=20
does not know anything about a sophie subprocess. It does not fetch the=20
subprocess ID from a pid file like the init.d start/stop scripts usually=20
do. It only gets the PID at the time, when it spawns the daemon. In case=20
of sophie, it is the PID of the main process.

You can reproduce the problem by sending a TERM signal directly to the=20
sophie main process. Doing so only terminates the main but not the child=20
process. This child process even stays alive after starting a new sophie=20
instance with a new main and subprocess.

I don=B4t know much about process signaling, spawning, forking etc. but=20
wouldn=B4t it be a cleaner way, if the sophie main process is made=20
responsable for it=B4s children? It could catch all incoming signals and=20
send them to it=B4s child process(es). So a SIGTERM signal sent to the=20
main process would also reach the children, the children will then=20
terminate and at the end the main process terminates itself.

I hope You now know what a mean. Thank You for Your help

Uwe


[email protected] wrote:

>Uwe,
>
>Sophie 3.04 and Sophie 3.04rc1/2 both switch to an unprivledged user (th=
e
>one specified in the user:, group: options in the sophie config file)  t=
o
>perform scans.  The difference is where they actually switch to this use=
r.
>
>Lets assume sophie is started as root.  In 3.04rc2, the main process wil=
l
>be running as root, which forks child processes to perform the actual
>scans.  The first thing these child processes to is a setgid, setuid to =
the
>non-root user, group (or whatever is specified in sophie.cfg).  In 3.04,
>the main process performs the setgid, setuid before the main loop so the
>main process and child processes are all running as the non-root user.
>This change was necessary because of some semaphores that were added to
>libsavi.  These have since been removed temporarily I believe, so 3.04rc=
2
>should work again.
>
>However, since both versions switch to an unprivileged user, and they us=
e
>the same code to do so, I'm not sure why you are having problems now.  I=
f
>you could provide some more detail as to what exactly the problem is, th=
e
>Sophie log, etc, then maybe we can help you out.
>
>Scott.
>
>[email protected] wrote on 09/20/2005 06:18:50 PM:
>
> =20
>
>>Hello List,
>>
>>we are using sophie 3.04rc1/2 under the daemontools control for years
>>without any problems.
>>Since the last update to release 3.04 there seems to be a significant
>>change in the way how sophie handles subprocesses.
>>I read that sophie is now responsable for starting subprocesses which
>>are run under an unprivileged user account. Does that mean that sophie
>>now needs to be run as root to be able to change the user for the
>>subprocess?
>>We never ran sophie as root so far. Under daemontools we always changed
>>to an unprivileged user with the setuidgid command before starting
>>   =20
>>
>sophie.
> =20
>
>>Is version 3.04 not compatible with daemontools any more? If so, was th=
e
>>change in source code absolutely necessary to work properly? What to do
>>to make it work under daemontools?
>>
>>Thanke You, Uwe
>>_______________________________________________
>>vtools mailing list
>>[email protected]
>>http://www.vanja.com/list/listinfo.cgi/vtools
>>   =20
>>
>
>_______________________________________________
>vtools mailing list
>[email protected]
>http://www.vanja.com/list/listinfo.cgi/vtools
>
>
> =20
>

--------------020207000508000905000609
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Scott,<br>
<br>
thank You for the fast reply, let me try to explain the problem we have.<br>
So far we prefered using bernstein&acute;s daemontools instead of the usual
init.d start/stop scripts to control the sophie daemon process.<br>
The use of daemontools garanteed reliable restarts of the sophie
process if it unexpectedly died. We have made good experiences with
daemontools so far.<br>
<br>
Now with sophie version 3.04, if I send signals to sophie (SIGTERM /
SIGHUP) by using the daemontools "svc" command, theses signals go to
the sophie main process and not to the subprocess. I don&acute;t have deeper
knowledge about the way daemontools work, but for me it seems that svc
does not know anything about a sophie subprocess. It does not fetch the
subprocess ID from a pid file like the init.d start/stop scripts
usually do. It only gets the PID at the time, when it spawns the
daemon. In case of sophie, it is the PID of the main process.<br>
<br>
You can reproduce the problem by sending a TERM signal directly to the
sophie main process. Doing so only terminates the main but not the
child process. This child process even stays alive after starting a new
sophie instance with a new main and subprocess.<br>
<br>
I don&acute;t know much about process signaling, spawning, forking etc. but
wouldn&acute;t it be a cleaner way, if the sophie main process is made
responsable for it&acute;s children? It could catch all incoming signals and
send them to it&acute;s child process(es). So a SIGTERM signal sent to the
main process would also reach the children, the children will then
terminate and at the end the main process terminates itself.<br>
<br>
I hope You now know what a mean. Thank You for Your help<br>
<br>
Uwe<br>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br>
<blockquote
 cite="midOF21C42890.4413F88C-ON49257088.0009927F-49257088.0009C92F@sophos.com"
 type="cite">
  <pre wrap="">Uwe,

Sophie 3.04 and Sophie 3.04rc1/2 both switch to an unprivledged user (the
one specified in the user:, group: options in the sophie config file)  to
perform scans.  The difference is where they actually switch to this user.

Lets assume sophie is started as root.  In 3.04rc2, the main process will
be running as root, which forks child processes to perform the actual
scans.  The first thing these child processes to is a setgid, setuid to the
non-root user, group (or whatever is specified in sophie.cfg).  In 3.04,
the main process performs the setgid, setuid before the main loop so the
main process and child processes are all running as the non-root user.
This change was necessary because of some semaphores that were added to
libsavi.  These have since been removed temporarily I believe, so 3.04rc2
should work again.

However, since both versions switch to an unprivileged user, and they use
the same code to do so, I'm not sure why you are having problems now.  If
you could provide some more detail as to what exactly the problem is, the
Sophie log, etc, then maybe we can help you out.

Scott.

<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote on 09/20/2005 06:18:50 PM:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hello List,

we are using sophie 3.04rc1/2 under the daemontools control for years
without any problems.
Since the last update to release 3.04 there seems to be a significant
change in the way how sophie handles subprocesses.
I read that sophie is now responsable for starting subprocesses which
are run under an unprivileged user account. Does that mean that sophie
now needs to be run as root to be able to change the user for the
subprocess?
We never ran sophie as root so far. Under daemontools we always changed
to an unprivileged user with the setuidgid command before starting
    </pre>
  </blockquote>
  <pre wrap=""><!---->sophie.
  </pre>
  <blockquote type="cite">
    <pre wrap="">Is version 3.04 not compatible with daemontools any more? If so, was the
change in source code absolutely necessary to work properly? What to do
to make it work under daemontools?

Thanke You, Uwe
_______________________________________________
vtools mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="http://www.vanja.com/list/listinfo.cgi/vtools">http://www.vanja.com/list/listinfo.cgi/vtools</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
_______________________________________________
vtools mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="http://www.vanja.com/list/listinfo.cgi/vtools">http://www.vanja.com/list/listinfo.cgi/vtools</a>


  </pre>
</blockquote>
</body>
</html>

--------------020207000508000905000609--

--===============0351171339==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

_______________________________________________
vtools mailing list
[email protected]
http://www.vanja.com/list/listinfo.cgi/vtools

--===============0351171339==--