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
On Mon, 22.08.11 15:16, Richard Shaw (hobbes1069@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
On Mon, Aug 22, 2011 at 3:53 PM, Lennart Poettering mzerqung@0pointer.de 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
On Mon, 22.08.11 19:54, Richard Shaw (hobbes1069@gmail.com) wrote:
On Mon, Aug 22, 2011 at 3:53 PM, Lennart Poettering mzerqung@0pointer.de 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,
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
On Tue, 23.08.11 08:14, Richard Shaw (hobbes1069@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
On Tue, Aug 23, 2011 at 9:19 AM, Lennart Poettering mzerqung@0pointer.de 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