Date: Mon, 8 Oct 2007 21:21:04 -0400 From: "Philip M. Gollucci" <philip@ridecharge.com> To: Stephen Allen <sdafreebsduk@rowyerboat.com> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Question about rc-scripts Message-ID: <470AD780.30702@ridecharge.com> In-Reply-To: <470AD44A.4070601@rowyerboat.com> References: <470AB2FC.8070006@rowyerboat.com> <6.0.0.22.2.20071008183414.025a1e88@mail.computinginnovations.com> <470AD44A.4070601@rowyerboat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Again, I thought the rc.subr functions took care of all that for you
> (unless you wanted something special from those commands).
>
In general, they do
see /etc/rc.subr:
check_pidfile(),
wait_for_pids(),
Most binaries i.e. httpd, memcached, mysqld, etc... provide a config
file or cli option to provide the path to a pid file.
If you look in the ports tree a lot of the patches are putting this in
the appropriate location: /var/run
The rc.subr then just uses them.
In general this system is very flexible. It breaks down if you wanted
to run say 2 distinct memcached daemons on different ports with
different pid files
via the /usr/local/etc/rc.d/<script>
> I've posted the script (changed quite a lot from vendor supplied) at:
> http://www.pastebin.ca/730238
>
Your particular problem is that run_rc_command actually exists so that
the script exists with the correct return code generally that of what
the application
in question returns from trying to start or stop.
Inless you have a reason, If you're running a daemon, you shouldn't need
to background the command.
Also, rather then an echo try adding -x to the shebang line.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?470AD780.30702>