spacenavd: Need help with systemd unit

[Richard Shaw]

I'm working on a review request for spacenavd[1] which is a daemon for
providing access to 3D input devices that use the library libspnav.

I have not built a package that uses sysv for systemd yet so this is my first.

I have a working sysv init script based on the provided template but
it would probably be better to start out a new package using systemd
instead.

Here's my first attempt at :
[Unit]
Description=Spacenav Daemon
After=syslog.target

[Service]
Type=Simple
ExecStart=/usr/bin/spacenavd

[Install]
WantedBy=graphical.target

Is this all I need? It does not depend on any other service that I know of.

Thanks,
Richard

[1] https://bugzilla.redhat.com/show_bug.cgi?id=731519

[Lennart Poettering]

On Mon, 22.08.11 15:16, Richard Shaw (hobbes1069(a)gmail.com) wrote:

>  I'm working on a review request for spacenavd[1] which is a
> daemon for
>  providing access to 3D input devices that use the library libspnav.
>  
>  I have not built a package that uses sysv for systemd yet so this is my first.
>  
>  I have a working sysv init script based on the provided template but
>  it would probably be better to start out a new package using systemd
>  instead.
>  
>  Here's my first attempt at :
>  [Unit]
>  Description=Spacenav Daemon
>  After=syslog.target
>  
>  [Service]
>  Type=Simple 
It's "simple", not "Simple", and since "simple is the default
anyway,
you can leave it out.

>  ExecStart=/usr/bin/spacenavd 
>  
>  [Install]
>  WantedBy=graphical.target
>  
>  Is this all I need? It does not depend on any other service that I know of. 
Depends. If this daemon provides some interface to local clients you
either want to make it socket activatable (requires patching) or use
"Type=forking" or so, so that we can properly order bootup.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Richard Shaw]

On Mon, Aug 22, 2011 at 3:53 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
[SNIP]
> > Is this all I need? It does not depend on any other service that
> I know of.
>
>  Depends. If this daemon provides some interface to local clients you
>  either want to make it socket activatable (requires patching) or use
>  "Type=forking" or so, so that we can properly order bootup. 
Can you elaborate a little?

What kind of patching are we talking about? Does the daemon need to be
systemd aware for socket activation?

If I go with forking, am I ready to go?

I did forward your response to upstream so hopefully they'll have some
helpful feedback to give.

Thanks,
Richard

[Lennart Poettering]

On Mon, 22.08.11 19:54, Richard Shaw (hobbes1069(a)gmail.com) wrote:

>  
>  On Mon, Aug 22, 2011 at 3:53 PM, Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
>  [SNIP]
>  >> Is this all I need? It does not depend on any other service that I know of.
>  >
>  > Depends. If this daemon provides some interface to local clients you
>  > either want to make it socket activatable (requires patching) or use
>  > "Type=forking" or so, so that we can properly order bootup.
>  
>  Can you elaborate a little?
>  
>  What kind of patching are we talking about? Does the daemon need to be
>  systemd aware for socket activation? 
You don't need to patch, if you use Type=forking.

>  If I go with forking, am I ready to go? 
I don't know your daemon and its parameters. If you use Type=forking
then the daemon should actually double fork. It should return in the
parent only after the dameon initialization is finished. The daemon
should write a PID file (and that PID file systemd should be informed
about with PIDFIle=...)

Type=simple just spawns off a daemon and does not wait for anything,
continues immediately with the next service to strt.

Type=forking spawns off a daemon and waits until it exits under the
assumption that it forked off the main daemon in the
background. Traditionally this is how Unix daemons notified the SysV
init scripts that they were now fully started up. 

Also see daemon(7).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Richard Shaw]

Lennart,

Here's the response from upstream:
"""
On Mon, Aug 22, 2011 at 04:09:34PM -0500, Richard Shaw wrote:
>  How exactly does spacenavd interface with applications? Is it some
>  sort of socket? 
Spacenavd provides two interfaces to applications:
- The libspnav-only interface which doesn't require a running X server
 uses a UNIX domain socket to communicate with applications.
- The compatibility interface which allows even programs written for the
 proprietary driver to continue working with spacenavd, communicates
 with applications through X11 ClientMessage events. The daemon uses
 inotify to figure out when the X server has started, by looking for
 sockets in /tmp/.X11-unix.

(Libspnav can in fact be used to write applications that utilize any or
both of the aformentioned protocols).

If you need any further information about how spacenavd works, feel free
to ask.

Cheers.

--
John Tsiombikas
"""


With that said, which method of startup would you recommend?

Thanks,
Richard

[Lennart Poettering]

On Tue, 23.08.11 08:14, Richard Shaw (hobbes1069(a)gmail.com) wrote:

>  
>  Lennart,
>  
>  Here's the response from upstream:
>  """
>  On Mon, Aug 22, 2011 at 04:09:34PM -0500, Richard Shaw wrote:
>  > How exactly does spacenavd interface with applications? Is it some
>  > sort of socket?
>  
>  Spacenavd provides two interfaces to applications:
>  - The libspnav-only interface which doesn't require a running X server
>   uses a UNIX domain socket to communicate with applications. 
So the daemon listens on a local socket. That means it's quite important
that systemd waits with starting the next service until your daemon
finished starting up (and hence finished establishing the listening
socket), so that the next service can rely that the listening socket is
connectable. That means Type=forking is a working choice.

In all cases using socket activation is preferable since it increases
parallelization, robustness and simplicity, but this requires patching,
as mentioned.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Richard Shaw]

On Tue, Aug 23, 2011 at 9:19 AM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  So the daemon listens on a local socket. That means it's quite
> important
>  that systemd waits with starting the next service until your daemon
>  finished starting up (and hence finished establishing the listening
>  socket), so that the next service can rely that the listening socket is
>  connectable. That means Type=forking is a working choice.
>
>  In all cases using socket activation is preferable since it increases
>  parallelization, robustness and simplicity, but this requires patching,
>  as mentioned. 
I verified it does create a PID file in /var/run so that looks like the winner.

Thanks for the help!

Richard