2013/4/24 Leonard de Ruijter <[email protected]>:
> Hello Romain and others,
Hi Leonard,
> I've made some significant progress and now have a working git
> buildpackage for Arch Linux.
Thanks for this work!
> Before I'm going to upload it to the Arch
> User Repo, I have the following remarks/questions:
> 1. The logrotate script contains the following postrotate script:
> postrotate
> for liq in /var/run/liquidsoap/*.pid ; do
> if test $liq != '/var/run/liquidsoap/*.pid' ; then
> start-stop-daemon --stop --signal USR1 --quiet --pidfile $liq
> fi
> done
> endscript
> Although start-stop-daemon is available in the arch repository, it isn't
> installed by default. I also didn't find the package installed by
> default on an OpenSuse system. How about using the more generic way of
> accomplishing the same?
> postrotate
> for liq in /var/run/liquidsoap/*.pid ; do
> if test $liq != '/var/run/liquidsoap/*.pid' ; then
> kill -s USR1 `cat $liq`
> fi
> done
> endscript
> It is still somewhat buggy. Imagine a situation where a liquidsoap
> daemon closes and the pidfile isn't being removed. I need to dive in
> this somewhat more to give a better solution to let the logrotate script
> whether the process is running before killing.
I think this is a very good suggestion. A lot of daemon-related things
in liquidsoap are very debian-specifics and we should get rid of them
or make then more portable.
As for the case where process has closed but PID file is still here, I
do not think it is a big deal and it's probably very unlikely that
another process has this PID and that a USR1 signal to that process
would cause any problem.
I will review this later and commit something, most probably your
version later (not in the next 10 days tho I fear), in the mean time
let us know what you end-up using for your package..
> Also, it would be nice if
> liquidsoap removes te PIDFile after closing.
So, liquidsoap was historically put in daemon mode through the
debian-specific start-stop-daemon. However, some time ago, support for
daemonized mode was also added in ocaml-dtools, which liquidsoap uses.
Thus, you should be able to ask liquidsoap to run in daemon mode,
either by setting:
set("init.daemon",false)
in your script or by using the --daemon option. If you go that route,
you will have several options that you can use, including:
set("init.daemon.pidfile",true)
set("init.daemon.pidfile.path","<sysrundir>/<script>.pid")
which should allow liquidsoap to write and remove PID file (or so I hope!)
> 2. When is the pidfile created in the daemonizing process?
> When i try to
> use my own sample systemd service, i get the following messages:
> systemd[1]: Starting Liquidsoap service for channel foo...
> systemd[1]: PID file /run/liquidsoap/foo.pid not readable (yet?) after
> start.
> systemd[1]: [email protected]: Supervising process 2564 which is
> not our child. We'll most likely not notice when it exits.
> systemd[1]: Started Liquidsoap service for channel foo.
> When Systemd tries to read the pidfile, it doesn't exist yet. This might
> be because the pidfile is created quite late in the daemonizing process.
> This is probably not only a problem with Systemd, but also with the
> start-stop-daemon init.d implementation Debian uses, which also needs
> the PIDFile to exist as quick as possible.
> May be there is a way to make the PID creation more fast or create it
> earlier in the process?
If you use the above method, I believe that PID file is written first
thing after forking, at least according to ocaml-dtools' code.
I have no knowledge re: systemd unfortunately.
Hope this helps,
Romain
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users