Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Jul 2005 21:28:17 -0500
From:      Paul Schmehl <pauls@utdallas.edu>
To:        freebsd-rc@freebsd.org
Subject:   Re: New port startup script fails
Message-ID:  <934769257EAE1C5FD99FD7E3@Paul-Schmehls-Computer.local>
In-Reply-To: <20050722004448.GB19090@odin.ac.hmc.edu>
References:  <468B58E789145A1C6885EA66@utd59514.utdallas.edu> <20050721230123.GA19090@odin.ac.hmc.edu> <B858D08121B1B491F0217584@utd59514.utdallas.edu> <20050722004448.GB19090@odin.ac.hmc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Thanks.  I haven't got it working yet, but I'll figure it out.

--On July 21, 2005 5:44:48 PM -0700 Brooks Davis 
<brooks@one-eyed-alien.net> wrote:

> On Thu, Jul 21, 2005 at 06:10:45PM -0500, Paul Schmehl wrote:
>> --On Thursday, July 21, 2005 16:01:23 -0700 Brooks Davis
>> <brooks@one-eyed-alien.net> wrote:
>>
>> > On Thu, Jul 21, 2005 at 05:50:12PM -0500, Paul Schmehl wrote:
>> >> I'm working on a new port, and I decided to use the new rc.subr type
>> >> startup script.  After I wrote the script, I started testing it.  The
>> >> program started fine, but neither stop nor status worked.  I read man
>> >> (8)  rc.subr and studied the script (/etc/rc.subr).
>> >>
>> >> The program was creating a pid file with the correct name in /var/run,
>> >> but  for some reason, the stop and status commands apparently couldn't
>> >> find?  read? the file.  Is there a way to troubleshoot this problem to
>> >> pin down  exactly were the problem is?
>> >
>> > Far too many things could be wrong for us to do more than speculate.
>> > Please send the script in question.
>> >
>> Here it is:  (%%SGUILDIR%% is converted to sguil-server in the Makefile)
>>
>> # !/bin/sh
>>
>> # PROVIDE: sguild
>> # REQUIRE: DAEMON
>> # BEFORE: LOGIN
>> # KEYWORD: FreeBSD shutdown
>>
>> # Add the following lines to /etc/rc.conf to enable sguild:
>> # sguild_enable (bool):         Set to YES to enable sguild
>> #                               Default: NO
>> # sguild_flags (str):           Extra flags passed to sguild
>> #                               Default: -D
>> # sguild_conf (str):            Sguild configuration file
>> #                               Default:
>> %%PREFIX%%/etc/%%SGUILDIR%%/sguild.conf
>> #
>>
>> . %%RC_SUBR%%
>>
>> name="sguild"
>> rcvar=`set_rcvar`
>>
>> command="%%PREFIX%%/bin/%%SGUILDIR%%/sguild"
>>
>> load_rc_config $name
>>
>> [ -z "$sguild_enable" ]    && sguild_enable="NO"
>> [ -z "$sguild_conf" ]      &&
>> sguild_conf="%%PREFIX%%/etc/%%SGUILDIR%%/sguild.conf"
>> [ -z "$sguild_flags" ]     && sguild_flags="-D"
>>
>> [ -n "$sguild_conf" ]      && sguild_flags="$sguild_flags -c
>> $sguild_conf"
>>
>> run_rc_command "$1"
>
> Looks mostly good.  You can use shell default values instead of the test
> -z stuff to set the variables if you want:
>
> sguild_enable=${sguild_enable:-NO}
>
>> > A couple of ideas.  First, are you setting the pidfile variable?
>>
>> No.  I can, but by default it is set to /var/run/sguild.pid.
>>
>> > If not, you may need to.
>>
>> Since $name is sguild, wouldn't the pid be sguild.pid?
>
> No, you have to set it since rc.subr supports commands without pid
> files.
>
>> > Second, does the program in question change it's
>> > name?  If so, you may have to implement stop and status by hand.
>>
>> I'm not sure I understand what you mean here.  However, there *is* one
>> oddity.  When the program is running, ps shows the command to be
>> "tclsh8.4  /usr/local/bin/sguil-server/sguild -D -c
>> /usr/local/etc/sguil-server/sguild.conf".
>>
>> Maybe that's the problem?  (I thought, since the pidfile was known that
>> it  wouldn't matter.)
>
> It's sort of both. The rc.subr framework only kills processing with the
> right name and the right pid (iff the pidfile is given) so that innocent
> processes aren't killed off with there are leftover PID files.  I looked
> at rc.subr and realized that there is support for interpreted commands,
> but you have to enable it by setting command_interpreter.  I'm not quite
> sure what to set it to.  It looks like the value is mostly ignored, but
> I'm not 100% sure.
>
> -- Brooks
>
> --
> Any statement of the form "X is the one, true Y" is FALSE.
> PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



Paul Schmehl (pauls@utdallas.edu)
Adjunct Information Security Officer
University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/



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