Re: [gpsd-users] GPSD under Debian 9.4: Systemd problems.

[Martin Burnicki]

Gary E. Miller wrote:
> Yo Charles!
> 
> On Thu, 21 Jun 2018 17:32:56 -0600 Charles Curley
> <address@hidden> wrote:
[...]
>> It looks like gpsd.service expects either /etc/default/gpsd or
>> /etc/sysconfig/gpsd. However udev-install provides neither. A 
>> work-around hack is to run gpsd manually.
> 
> That is because those are distro dependent.  That is for
> maintainers to add.

I also had to take care about this, though this was not with gpsd.

IMO, if possible, a software package providing a daemon should come
with a run control script, if possible.

It's *much* easier to provide a single systemd configuration file for
the daemon than providing init scripts for different Linux distros,
since many distros expect a different syntax for the init scripts,
while systemd usually works the same way on all distros.

Of course there may be differences between distros running current
systemd versions vs. distros running *very* old versions of systemd.

>> gpsd.service expects to find gpsd at /usr/sbin/gpsd.
> 
> Yes, when installing gpsd from a distro package.
> 
>> However, "scons udev-install" puts it at /usr/local/sbin/.
> 
> Yes, as a git/source install should.  This is the Unix way.  User 
> packages go in /usr/local.  Distro packages go in /usr.

Agreed.

>> Is it possible for systemd to look for it in both places?
> 
> Dunno, I don't do systemd.  But if scons installs anything it
> should not be going in /etc/ at all/  That is for distro installed
> packages. Any git/source install needs to go into /usr/local/etc/
> 
>> Or have systemd-install hack that line after copying it in?

IMO it would be better if the gpsd package was shipped with an own
systemd configuration file.

> Not sure the solution.  The current situation of gpsd and systemd
> is a mess.  Never worked well.

I think this is a general problem which is not related to systemd.

If you have *any* program installed from a distro package *and*
another version compiled on your own then you even have to take care.

If you simply run it from the command line (without specifying the
full path) you run the version that is found first in the PATH, which
may not not be the one you expected to run. Yes I know that USUALLY
/usr/local/... is searched first, but ...

Also, if there are old fashon init scripts then these have often also
the path to the executable file hardcoded, so if the script is from a
distro package it won't find your own compiled binary, either, so
there's no difference to the problem observed with systemd.


An interesting question is if systemd would look into /usr/local/etc
for overrides, similar to the path overrides, but the same question is
if the older init scripts would support this.

So, if anyone comes up with a good idea how to avoid this confusion
... ;-)

Martin