You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Grzegorz B. Prokopski" <ga...@debian.org> on 2004/06/20 03:06:50 UTC
svnserve could save its PID somewhere
Hi,
Before filling in a wishlist bug, I am supposed to discuss it here
(according to "Issue Tracker Guidelines"), so here it goes.
I am in process of setting up different services in chroots
without /proc. This works just fine for pretty much all services as
most of daemons leave their "main deamon PID" in some .pid file,
usually in /var/run/$name.pid or /var/run/$name/$name.pid.
The PID is necessary to send a signal to daemon when we want it
to finish execution (and shut down nicely) [*]
For anonymous access to our repositories I wanted to setup
svnserve in a similar way. But apparently svnserve has no option
to create the .pid file. Therefore I wanted to ask you whether
it could be added, so that something of that shape worked:
$ svnserve -d -p /var/run/svnserve/svnserve.pid
There are of course several possible (ugly) workarounds, like:
a) 'killall svnserve' - requires /proc, and can kill any process
with this name, especially if killall is ran as root,
b) use --foreground option and force detach in start-stop-daemon
(this is debian utility havily used in /etc/init.d scripts),
then I'll be able to use PID taken by start-stop-daemon to
stop the server (this is even _documented_ as "last resort",
ugly method in s-s-d manual page).
On the contrary - I imagine this -p option should be rather trivial
to add and would solve this issue entirely, like it's done in all
other daemons.
Or is there any particular reason why it's not good idea?
Regards,
Grzegorz B. Prokopski
[*] Btw: what signal should I send to svnserve to let it know
that I want it to shut down? Is simple TERM (15) the way to go?
PS: I'll be thankful for Cc:ing me on replies.
--
Grzegorz B. Prokopski <ga...@debian.org>
Debian GNU/Linux http://www.debian.org
SableVM - LGPLed JVM http://www.sablevm.org
Why SableVM ?!? http://devel.sablevm.org/wiki/Features
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Mon 2004-06-21 at 00:28:38 +0200, Branko ??ibej wrote:
> Tobias Ringström wrote:
> >Branko ??ibej wrote:
> >
> >>Shouldn't be hard to do. You still have to catch the signal, then
> >>have the main thread simply terminate. The process should wither away
> >>once the other threads have exited, I think. But we do need the
> >>sighnal handlers. Also, svnserve should reread its config files (if
> >>any) if it sees a SIGHUP. That's just common behaviour.
> >
> >AFAIK, if you exit from main, all threads get terminated.
>
> That may be true on Unix with pthreads,
I'll try to clarify... I am not sure what "exit from main" is meant to
mean in this context, but AFAIK (with pthreads under Unix):
- calling exit() anywhere (or in any thread) will cause all threads to
terminate.
- pthread_exit() will terminate the current thread without affecting
the others
- "return" in main (in the main thread), is equivalent to exit()
- "return" elsewhere, is equivalent to calling pthread_exit()
(i.e. returning from the function a specific thread was started with)
So, if it's possible to arrange to call pthread_exit(), everything
should work as needed for the suggested solution.
Bye,
Benjamin.
PS: At least for QNX 6.2 I have actually tested that pthread_exit()
called in the main thread will leave the others threads running as
expected.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Branko Čibej <br...@xbc.nu>.
Tobias Ringström wrote:
> Branko Čibej wrote:
>
>> Shouldn't be hard to do. You still have to catch the signal, then
>> have the main thread simply terminate. The process should wither away
>> once the other threads have exited, I think. But we do need the
>> sighnal handlers. Also, svnserve should reread its config files (if
>> any) if it sees a SIGHUP. That's just common behaviour.
>
> AFAIK, if you exit from main, all threads get terminated.
That may be true on Unix with pthreads, but Windows works differently.
Which means we're in a bit of a fix, because AFAIK APR doesn't abstract
that difference.
> You need to create the threads without making them detached, and then
> call join before returning from main. It's not a big thing, but it
> requires some housekeeping. It would be useful to implement a maximum
> number of clients at the same time, and a timeout for the clients.
You can't do that, because some requests are dependent on each other, so
that the client blocks on _two_ RA sessions (diff and merge will
generate such, for example), but the server can't know for sure which
requests these are. I started implementing thread pools in svnserve
(stopped that because APR condition variables don't work correctly on
Windows), and it turns out you need as many threads as there are active
requests to be safe. The best you can do is set a _minimum_ number of,
and a timeout for, idle threads.
But that's getting ahead of the issue. We should get termination
detection in first, then go on from there. For a threaded server, we
could keep a list of active threads and simply wait for them to
terminate before exiting the server. Maybe even propagate the
termination signal as a cancellation.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-06-21 at 05:59, Tobias Ringström wrote:
> That's not what I was talking about. Because the child processes don't
> close the listening socket, it will still be open even if you kill the
> parent process.
Ah, yes, now I understand. I agree, that's a bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Branko Čibej wrote:
> Greg Hudson wrote:
>
>> On Sun, 2004-06-20 at 14:22, Tobias Ringström wrote:
>>
>>> Oops, I see that the children are not closing the listening socket.
>>> As you say it's not strictly neccessary, but it's still a bug. I'll
>>> fix it. It should be a one-liner.
>>
>> (1) Won't APR pool cleanups take care of this?
>
> Not if you kill the process and it doesn't catch the signal and exit
> cleanly. :-)
That's not what I was talking about. Because the child processes don't
close the listening socket, it will still be open even if you kill the
parent process. That in turn means that you cannot start a new server
process until all children have terminated because the port will be
busy. Clients trying to connect to the server while the main process is
terminated by childred still exist will hang instead of abort until the
last child terminate.
>> (2) How is it a bug?
>
> It's not.
It's not an end of the world kind of bug, but it still a bug. But I
suspect that we were talking about different things.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Sun, 2004-06-20 at 14:22, Tobias Ringström wrote:
>
>
>>Oops, I see that the children are not closing the listening socket. As
>>you say it's not strictly neccessary, but it's still a bug. I'll fix
>>it. It should be a one-liner.
>>
>>
>
>(1) Won't APR pool cleanups take care of this?
>
>
Not if you kill the process and it doesn't catch the signal and exit
cleanly. :-)
>(2) How is it a bug?
>
>
It's not.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-06-20 at 14:22, Tobias Ringström wrote:
> Oops, I see that the children are not closing the listening socket. As
> you say it's not strictly neccessary, but it's still a bug. I'll fix
> it. It should be a one-liner.
(1) Won't APR pool cleanups take care of this?
(2) How is it a bug?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Branko Čibej wrote:
> Tobias Ringström wrote:
>> On unix, svnserve uses fork by default. The main process is only a TCP
>> listener and it does not open the repository. For each connection a
>> child is forked that opens the repository. As long as you only kill
>> the main process you're safe,
>
> Well, at least closing the sockets and such would be nice, although it's
> not strictly necessary.
Oops, I see that the children are not closing the listening socket. As
you say it's not strictly neccessary, but it's still a bug. I'll fix
it. It should be a one-liner.
>> but if you kill one of the children, the repository will need
>> recovery. There is no way to safely stop a threaded svnserve, though. :-(
>
> Shouldn't be hard to do. You still have to catch the signal, then have
> the main thread simply terminate. The process should wither away once
> the other threads have exited, I think. But we do need the sighnal
> handlers. Also, svnserve should reread its config files (if any) if it
> sees a SIGHUP. That's just common behaviour.
AFAIK, if you exit from main, all threads get terminated. You need to
create the threads without making them detached, and then call join
before returning from main. It's not a big thing, but it requires some
housekeeping. It would be useful to implement a maximum number of
clients at the same time, and a timeout for the clients.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Branko Čibej <br...@xbc.nu>.
Tobias Ringström wrote:
> Branko Čibej wrote:
>
>> Grzegorz B. Prokopski wrote:
>>
>>> [*] Btw: what signal should I send to svnserve to let it know
>>> that I want it to shut down? Is simple TERM (15) the way to go?
>>
>>
>> Come to think of it, svnserve doesn't handle signals as well as it
>> should -- it should use some of the logic from the client, or
>> svnlook. Once that's done, SIGTERM should be just fine.
>
>
> On unix, svnserve uses fork by default. The main process is only a TCP
> listener and it does not open the repository. For each connection a
> child is forked that opens the repository. As long as you only kill
> the main process you're safe,
Well, at least closing the sockets and such would be nice, although it's
not strictly necessary.
> but if you kill one of the children, the repository will need
> recovery. There is no way to safely stop a threaded svnserve, though. :-(
Shouldn't be hard to do. You still have to catch the signal, then have
the main thread simply terminate. The process should wither away once
the other threads have exited, I think. But we do need the sighnal
handlers. Also, svnserve should reread its config files (if any) if it
sees a SIGHUP. That's just common behaviour.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Branko Čibej wrote:
> Grzegorz B. Prokopski wrote:
>
>> [*] Btw: what signal should I send to svnserve to let it know
>> that I want it to shut down? Is simple TERM (15) the way to go?
>
> Come to think of it, svnserve doesn't handle signals as well as it
> should -- it should use some of the logic from the client, or svnlook.
> Once that's done, SIGTERM should be just fine.
On unix, svnserve uses fork by default. The main process is only a TCP
listener and it does not open the repository. For each connection a
child is forked that opens the repository. As long as you only kill the
main process you're safe, but if you kill one of the children, the
repository will need recovery. There is no way to safely stop a threaded
svnserve, though. :-(
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Branko Čibej <br...@xbc.nu>.
Grzegorz B. Prokopski wrote:
>Hi,
>
>Before filling in a wishlist bug, I am supposed to discuss it here
>(according to "Issue Tracker Guidelines"), so here it goes.
>
>I am in process of setting up different services in chroots
>without /proc. This works just fine for pretty much all services as
>most of daemons leave their "main deamon PID" in some .pid file,
>usually in /var/run/$name.pid or /var/run/$name/$name.pid.
>The PID is necessary to send a signal to daemon when we want it
>to finish execution (and shut down nicely) [*]
>
>For anonymous access to our repositories I wanted to setup
>svnserve in a similar way. But apparently svnserve has no option
>to create the .pid file. Therefore I wanted to ask you whether
>it could be added, so that something of that shape worked:
>
> $ svnserve -d -p /var/run/svnserve/svnserve.pid
>
>
Of course this coule be added. It should be quite simple, too. Care to
write a patch?
>[*] Btw: what signal should I send to svnserve to let it know
>that I want it to shut down? Is simple TERM (15) the way to go?
>
Come to think of it, svnserve doesn't handle signals as well as it
should -- it should use some of the logic from the client, or svnlook.
Once that's done, SIGTERM should be just fine.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by John Peacock <jp...@rowman.com>.
Grzegorz B. Prokopski wrote:
> Before filling in a wishlist bug, I am supposed to discuss it here
> (according to "Issue Tracker Guidelines"), so here it goes.
Thanks for reading the guidelines first!
> b) use --foreground option and force detach in start-stop-daemon
> (this is debian utility havily used in /etc/init.d scripts),
> then I'll be able to use PID taken by start-stop-daemon to
> stop the server (this is even _documented_ as "last resort",
> ugly method in s-s-d manual page).
FWIW, I am planning on making '--foreground' a much more usuable switch next
month (during OSCON). One of the things I find lacking with svnserve is the
complete absence of logging.
I'm also annoyed by svnserve's lack of signal support (it has bitten me more
than once). I prefer to run my services under daemontools, and normally do
svc -t /service/svnserve
to try and restart the service (like if I change the configuration file) or
svc -dx /service/svnserve
if I want to stop the service entirely. I'll take a look at the signal support
at the same time (if no one beats me to it).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve could save its PID somewhere
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-06-19 at 23:06, Grzegorz B. Prokopski wrote:
> $ svnserve -d -p /var/run/svnserve/svnserve.pid
Sure, that would be fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org