Paul Schmehl wrote:
--On June 10, 2009 7:09:17 PM -0700 Drew Tomlinson <> wrote:

All I want to do is create a script within the rc.d framework that runs
"/usr/local/urchin/bin/urchinctl start" when the system boots and
"/usr/local/urchin/bin/urchinctl stop" when the system shuts down.

Following the examples in the guide mentioned above, here is my attempt
at that file:

# !/bin/sh
# PROVIDE: urchin
# KEYWORD: shutdown
# Add the following line to /etc/rc.conf to enable urchin:
# urchin_enable="YES" (bool):   Set to "NO" by default.
#                               Set it to "YES" to enable urchin.
. /etc/rc.subr
command="/usr/local/urchin/bin/urchinctl "
eval "${rcvar}=\${${rcvar}:-'NO'}"
load_rc_config $name
run_rc_command "$1"

I have also ensured that 'urchin_enable="YES"' is in /etc/rc.conf.
However when I run the rc.d script, the urchinctl appears to run but
doesn't like whatever arguments that are passed.  See this output:

urchin# ./urchin-server start
Starting urchin.

Usage: urchinctl [-v] [-h] [-e] [-s|-w] [-p port] action
<snipped rest of options already shown above>

I'm sure I'm missing some simple concept. I'd really appreciate a kick
in the right direction.

Where is urchin located?  /usr/local/bin?  /usr/local/bin/urchin/bin?
Or somewhere else?  Is urchinctl a shell or perl script?

There is no actual "urchin" as far as I know.  The control file is
/usr/local/urchin/bin/urchinctl.  It is a executable file:

urchin# file /usr/local/urchin/bin/urchinctl
/usr/local/urchin/bin/urchinctl: ELF 32-bit LSB executable, Intel 80386,
version 1 (FreeBSD), statically linked, stripped

After running "/usr/local/urchin/bin/urchinctl start", I have these
related processes:

urchin# ps acux | grep urchin
root    70937  0.0  0.0  3184  1996  ??  Ss    7:00PM   0:00.01
nobody  70938  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
nobody  70939  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
nobody  70940  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
nobody  70941  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
nobody  70942  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
nobody  70944  0.0  0.0  1460   720  ??  Ss    7:00PM   0:00.03 urchind
nobody  70946  0.0  0.0  1332   668  ??  Is    7:00PM   0:00.51 urchind

And conversely, "/usr/local/urchin/bin/urchinctl stop" removes all of
the above processes.

In your script command is path_to_urchinctl. rc.subr will look for a process named urchinctl and a pidfile named It appears that neither will be found, so the script can't stop or restart the processes, because it doesn't know the pid and therefore the process that it needs to kill. That doesn't explain why it won't start the processes though. I *think* you need to name the script urchin rather than urchin-server, but I can't test that.

The rc script name does not seem to matter.

To fix the pid problem, rc.subr offers some optional statements that, with the proper arguments, can overcome the problem. You'll have to read man rc.subr and test it to figure out what works, but here's an example that might work:


The problem here is that urchinctl does not write a pid file by default and I can't figure out how to make it do so.

However in reading man rc.subr, I found argument_cmd that works for me. By setting argument_cmd, I can override the default methods called by run_rc_command. Thus I set these three lines:

start_cmd="/usr/local/urchin/bin/urchinctl start"
stop_cmd="/usr/local/urchin/bin/urchinctl stop"
status_cmd="/usr/local/urchin/bin/urchinctl status"

Originally, I used "$1" instead of start, stop, and status. However this had the effect of making "restart" restart twice, once for the start method and once for the stop method because "/usr/local/urchin/bin/urchinctl restart" was being run each time.

If that does work, your script should at least be able to report the status (running or not).

I also had to set the procname variable to make the status method available. In my case, it didn't matter to what it was set as the urchinctl command handled the actual status reporting.

I'm assuming that, because root is running the lowest numbered process, killing that process will kill all the children as well.
Killing the root process killed all the urchinwebd processes but left the urchind processes hanging around. But no matter, I got things working.

Thanks for your help!


Be a Great Magician!
Visit The Alchemist's Warehouse

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to