Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Jun 2009 22:09:55 -0500
From:      Paul Schmehl <pschmehl_lists@tx.rr.com>
To:        Drew Tomlinson <drew@mykitchentable.net>
Cc:        freebsd-questions@FreeBSD.org
Subject:   Re: Help With rc.d Script
Message-ID:  <84015F2050B2B2480B0E0C49@Macintosh-2.local>
In-Reply-To: <4A30674D.1040804@mykitchentable.net>
References:  <6322EB049C37BA76C25CD076@Macintosh-2.local> <4A30674D.1040804@mykitchentable.net>

next in thread | previous in thread | raw e-mail | index | archive | help
--On June 10, 2009 7:09:17 PM -0700 Drew Tomlinson 
<drew@mykitchentable.net> 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
>>> # REQUIRE: NETWORKING
>>> # 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
>>> name="urchin"
>>> rcvar=`set_rcvar`
>>> 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
> urchinwebd
> nobody  70938  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
> urchinwebd
> nobody  70939  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
> urchinwebd
> nobody  70940  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
> urchinwebd
> nobody  70941  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
> urchinwebd
> nobody  70942  0.0  0.0  3184  2000  ??  I     7:00PM   0:00.00
> urchinwebd
> 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 urchinctl.pid.  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.

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:

pidfile="/var/run/urchinwebd.pid
check_pidfile="${pidfile}

If that does work, your script should at least be able to report the 
status (running or not).  I'm assuming that, because root is running the 
lowest numbered process, killing that process will kill all the children 
as well.

Paul Schmehl, If it isn't already
obvious, my opinions are my own
and not those of my employer.
******************************************
WARNING: Check the headers before replying




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84015F2050B2B2480B0E0C49>