Re: Help With rc.d Script -- SOLVED

2009-06-11 Thread Drew Tomlinson

Paul Schmehl wrote:
--On June 10, 2009 7:09:17 PM -0700 Drew Tomlinson 
d...@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
root70937  0.0  0.0  3184  1996  ??  Ss7: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  ??  Ss7:00PM   0:00.03 urchind
nobody  70946  0.0  0.0  1332   668  ??  Is7: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.


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:


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


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!

Drew

--
Be a Great Magician!
Visit The Alchemist's Warehouse

http://www.alchemistswarehouse.com

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Help With rc.d Script -- SOLVED

2009-06-11 Thread Mel Flynn
On Thursday 11 June 2009 05:45:59 Drew Tomlinson wrote:
 Paul Schmehl wrote:
  --On June 10, 2009 7:09:17 PM -0700 Drew Tomlinson
 
  d...@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
  root70937  0.0  0.0  3184  1996  ??  Ss7: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  ??  Ss7:00PM   0:00.03 urchind
  nobody  70946  0.0  0.0  1332   668  ??  Is7: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.

 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:
 
  pidfile=/var/run/urchinwebd.pid
  check_pidfile=${pidfile}

 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.

Right. This ctl basically does what rc scripts are normally doing. So this is 
the 20% case where many of rc's assumptions are incorrect and you need to 
override this logic. The main is that the command is not the running daemon. 
As such, one need to override the default start, stop, restart and status 
commands.
-- 
Mel
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Help With rc.d Script -- SOLVED

2009-06-11 Thread Paul Schmehl
--On Thursday, June 11, 2009 08:45:59 -0500 Drew Tomlinson 
d...@mykitchentable.net wrote:


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.



Drew, I'm glad you were able to get it working.  There may be a way to kill the 
urchind processes as well.   If you set procname to urchin, the rc.subr script 
might understand that to mean any process that begins with that string.  I 
haven't tested it, but looking at the script (/etc/rc.subr), it appears to me 
to be the case.  If that doesn't work, perhaps procname urchin* would.


--
Paul Schmehl (pa...@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/