in reply to Daemon::Control pid-files

Hi morgon,

ikegami already said it, but in the module's source you can see that do_stop is the only place unlink is called on the PID file.

Taking a step back though: I understand that your process is something that just runs once briefly and then exits. Aside from the question as to whether you need a PID file in the first place (is your script called multiple times?) and whether you need to delete the PID file at all, I wouldn't really see the task you describe as a continually-running daemon - instead I might just set that up via cron.

Is this something like "dvbdate" (1, 2)? If so, that can be set up to run regularly in the crontab - which by the way also has a @reboot directive for running things once on startup (haven't used that myself but it sounds pretty simple).

If you really want to use an init script (which has the advantage that it can be run immediately on boot and you can control the prerequisites), you could use Daemon::Control's ability to generate an init script for you, and then adapt that to suit your needs. For example, if I use the get_init_file command on your script, I get something like this (edited for brevity):

#!/bin/sh ### BEGIN INIT INFO # Provides: Time from DVB # Required-Start: $syslog $remote_fs # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 ### END INIT INFO` if [ -x /tmp/timeset_daemon.pl ]; then /tmp/timeset_daemon.pl $1 else echo "Required program /tmp/timeset_daemon.pl not found!" exit 1; fi

Then, just replace /tmp/timeset_daemon.pl by whatever command sets the time from the DVB stick, and it'll be run once on boot (and on shutdown, but that shouldn't matter here). Another sample init script is shown in this article, it also shows the usage of the update-rc.d command. You could also teach that script to respect the start|stop|status commands, but since your script isn't really a continually-running daemon, Daemon::Control might not be the optimal way to do that. Or, you can slap a while (1) { my_code_here; sleep($interval) } around your code and you've basically got a daemon.

I just recently started working with chrony to replace ntpd and provide accurate time via a GPS receiver on a Raspberry Pi, and it really was much easier to set up than ntpd. If you're looking into giving your RPi accurate time, then somehow feeding the DVB stick's time into chrony might be something worth investigating.

Hope this helps,
-- Hauke D

Replies are listed 'Best First'.
Re^2: Daemon::Control pid-files
by morgon (Priest) on Apr 17, 2016 at 21:35 UTC
    Hi

    thanks for replying.

    As I explained in another post I wanted to use a sysv-init script so I can specify when to run it via LSB-entries.

    Daemon::Control is handy has it can generate init-scripts but requires a pid-file even though I don't really need one, but the fact that it is not deleted does not really bother me.

    And for my purposes it is quite enough to extract the time-information from the dvb-c signal and set the time once.

    I also have ntpd running on my Pi (I don't quite understand how chrony could be easier as that was rather trivial) for those times when it is connected to the internet, but most of the time my pi is not.

      Hi morgon,

      In that case I'd suggest to just write your own init script based on one of the templates I mentioned, or maybe the extensive /etc/init.d/skeleton if your system has it. Since an init script is just a shell script, you can do all your work there - in fact I even wrote an init script in Perl once - or you can write a simple init script whose start action simply runs the Perl script that sets the time. Since your task is just a one-off thing, you don't need all the complexities of a "real" init script, including Daemon::Control (for example you likely don't need the double-fork, PID file, etc.).

      My understanding is that ntpd works best for systems that are continually on the network, talking to multiple time servers, while chrony was designed with systems with intermittent or no internet access at all in mind. Telling ntpd which Internet NTP servers to sync to is easy; but I was having lots of trouble getting ntpd to sync to gpsd and a "Pulse Per Second" (PPS) signal, with chrony it was much easier to configure and it basically worked right away.

      Regards,
      -- Hauke D

        Yeah - Deamon::Control is overkill but as it generates the init-file it seems to be the fastest way (in terms of lazyness) to have a perl-subroutine run at boot-time.

        And thanks for mentioning chrony - never heard of it before but will have a look at it.