[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Diffs for running svnserve as a Win32 service

From: Arlie Davis <adavis_at_stonestreetone.com>
Date: 2006-02-23 02:26:09 CET

Ok, here's the first cut of the service implementation. I welcome feedback,
testing, etc. Before sending any feedback, though, please read the
instructions below, especially the "Known Issues" section.

Thanks.

-- arlie

Windows Service Support for svnserve
------------------------------------

This patch allows svnserve to run as a Windows service.

This patch was written by Arlie Davis, February 2006. Please send all
feedback, bugs, etc. to dev@subversion.tigris.org, and to
adavis@stonestreetone.com.

*** NOTE: This patch is NOT yet ready for prime time! It still needs
          to be reviewed, tested, etc.

--
Arlie Davis
adavis@stonestreetone.com
arlie@sublinear.org
Installation
------------
For now, no means is provided to install the service.  Windows XP and
Windows 2003 Server provide a command-line tool for installing services.
To create a service for svnserve, invoke SC.EXE like so:
   sc create <name> binpath= "c:\svn\bin\svnserve.exe --service <svn-args>"
where <name> is any service name you want, e.g. "svnserve", and <svn-args>
are the arguments to svnserve, such as --root, --listen-port, etc.
In order for svnserve to run as a Windows service, you MUST specify the
--service argument, and you must NOT specify any other run mode argument,
such as --daemon, --tunnel, --inetd, or any of their short forms.  There
is no short form for --service.
SC has many options; use "sc /?".  The most useful are:
   sc create <name>     create a new service
   sc qc <name>         query config for a service
   sc query <name>      query status
   sc delete <name>     delete any service -- BE CAREFUL!
   sc config <name> ... update service config; same args as sc create
   sc start <name>      start a service (does NOT wait for completion!)
   sc stop <name>       stop a service (does NOT wait for it to stop!)
Note that the command-line syntax for SC is rather odd.  Key/value
pairs are specified as "key= value".  The "key=" part must not have
any spaces, and the "value" part MUST be separated from the "key="
by a space.
If you want to be able to see the command shell, add these arguments 
to the "sc create" command-line:
   type= own type= interact
This sets the "interactive" bit on the service, which allows it to interact
with the local console session.
You can create as many services as you like; there is no restriction on
the number of services, or their names.  I use a prefix, like "svn.foo",
"svn.bar", etc.  Each service runs in a separate process.
Uninstalling
------------
To uninstall a service, stop the service, then delete it.  That's all
there is to it.
Running on Startup
------------------
By default, SC creates the service with the start mode set to "demand"
(manual).  If you want the service to start automatically when the system
boots, add "start= auto" to the command line.  You can change the start
mode for an existing service using "sc config <name> start= auto", or
also by using the Windows GUI interface for managing services.  (Start,
All Programs, Administrative Tools, Services, or just run "services.msc"
from Start/Run or from a command-line.)
Starting and Stopping the Service
---------------------------------
You start and stop the service like any other Windows service.  You can
use the command-line "net start <name>", use the GUI Services interface.
Debugging
---------
Debugging a Windows service can be difficult, because the service runs in
a very different context than a user who is logged in.  By default, services
run in a "null" desktop environment.  They cannot interact with the user
(desktop) in any way, and vice versa.
Also, by default, services run as a special user, called LocalSystem.
LocalSystem is not a "user" in the normal sense; it is an NT security ID
(SID)
that is sort of like root, but different.  LocalSystem typically does NOT
have access to any network shares, even if you use "net use" to connect
to a remote file server.  Again, this is because services run in a different
login session.
Depending on which OS you are running, you may have difficulty attaching
a debugger to a running service process.  Also, if you are having trouble
*starting* a service, then you can't attach to the process early enough to
debug it.
So what's a developer to do?  Well, there are several ways you can debug
services.  First, you'll want to enable "interactive" access for the
service.
This allows the service to interact with the local desktop -- you'll be able
to see the command shell that the service runs in, see console output, etc.
To do this, you can either use the standard Windows Services tool
(services.msc),
or you can do it using sc.exe.
   * With the GUI tool, open the properties page for a service, and go 
     to the "Log On" page.  Select "Local System account", and make sure 
     the "Allow service to interact with desktop" box is checked.
     
   * With SC.EXE, configure the service using the command:
   
         sc <name> config type= own type= interact
     
     Yes, you must specify type= twice, and with exactly the spacing shown.
     
In both cases, you'll need to restart the service.  When you do, if the
service started successfully, you'll see the console window of the service.
By default, it doesn't print anything out.
Next, you'll want to attach a debugger, or configure the service to start
under a debugger.  Attaching a debugger should be straightforward -- just
find the process ID.  But if you need to debug something in the service 
startup path, you'll need to have a debugger attached from the very
beginning.
There are two ways to do this.  
In the first method, you alter the command-line of the service (called the
"binary path").  To do this, use SC.EXE to set the binary path to whatever
debugger you are going to use.  I use the most recent version of WinDbg,
which is excellent, and is available at:
   http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
For example, this command would configure the service to start under a
debugger:
   sc config <name> binpath= "d:\dbg\windbg.exe -g -G
d:\svn\bin\svnserve.exe
      --root d:\path\root --listen-port 9000"
The entire command must be on a single line, of course, and the binary path
must be in double-quotes.  Also, the spacing MUST be:  binpath= "..."
Substitute whatever debugger you want, with whatever command-line you want,
in place of windbg.exe.  Then start the service (sc start <name>), and the
Service Control Manager should execute the command-line you provided as
the binary path.  Then your debugger should start, and should launch the
svnserve process.
Known Issues
------------
* Source code does not (yet) conform to SVN conventions.  Yes, I plan on
  editing it so that it does.
  
* No management tool (installer, etc.).  For the first revision, this is
  intentional; we just want to get the service functionality tested and
  committed before dealing with installation.
* Right now, I don't know of a way to cleanly stop the svnserve process.
  Instead, the implementation closes the listen socket, which causes the
  main loop to exit.  This isn't as bad as it sounds, and is a LOT better
  than other options (such as terminating a thread).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Thu Feb 23 02:25:40 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.