Re: Question about an rc.d script in a package

[Greg Troxel <gdt%lexort.com@localhost>]

"Ivan \"Rambius\" Ivanov" <rambiusparkisanius%gmail.com@localhost> writes:

> I am creating a pkgsrc package for education purposes. The application
> it packages consists of a shell script that controls a daemon process
> and a client script that connects to that daemon. I want to manage the
> daemon process via rc.d. The control script has actions to start, stop
> and give the status of the daemon process. The start action saves the
> pid of the daemon process that it starts in the background, the status
> action prints the pid, and the stop action kills the pid.

That all sounds fine.

> I created a working rc.d script that simply wraps my control script. I
> feel that the latter duplicates a lot of functionality already
> implemented in rc.subr and I would like to eliminate the duplication.

It really isn't duplication as much as adapting to the interface.  A lot
of the point of rc.d scripts is that there is a standard set of commands
and you can use the rc.d script without having any idea about the
package.

I would think your rc.d script is very simple.

> The application is at https://github.com/rambius/ncatchat.
> https://github.com/rambius/ncatchat/blob/main/ncatchatsrv.sh uses the
> ncat command from nmap to start a chat server.
> https://github.com/rambius/ncatchat/blob/main/ncatchat.sh is the
> client that uses again the ncat command to connect to the server.
>
> The pkgsrc package is at https://github.com/rambius/pkgsrc-ncatchat.
> It uses NO_BUILD=YES, because it has nothing to build. It declares
> nmap as a dependency, because it takes the ncat command from it. It
> adds ncatchatd as an rc.d script to RCD_SCRPTS. The rc.d script
> resides in files/ncatchatd.sh at
> https://github.com/rambius/pkgsrc-ncatchat/blob/main/chat/ncatchat/files/ncatchatd.sh.
> I set PKG_RCD_SCRIPTS=yes in /etc/mk.conf and it copies the rc.d
> script directly to /etc/rc.d/ncatchatd on "make install".
>
> Everything works fine, but I saw some other rc.d scripts defining a
> variable "pidfile=..." and they let rc.d systems handles the status
> and stop commands and I would like to use this approach if possible.

See rc.subr and check_pidfile, and comment about run_rc_command.  This
is a way to express the standard approach of (saying this loosely from
skimming the code)

  start just runs the daemon command, It expects it to go into
  background by itself and to write a pidfile in /var/run/progname.pid
  when it starts.  I see this is a common source of bugs - one view is
  that the foreground process should not exit in favor of the child
  until whatever things that depend on this package (in terms of
  rcorder) have been done.
  
  status sees if a process with the pid in the pidfile is running

  stop sends SIGTERM to that pid
  
So this is more or less saying that start action in your script really
belongs in the daemon.   And conversely, if the daemon doesn't do this,
then it isn't really a daemon, just a program that can be run in the
background, and your control script *is* the daemon.    But then you are
doing tail call optimization by having the control script write the
child pid instead of its pid and exit.

I think you can address this by running the control script (making it
start by default with no args, like its a daemon), setting the pidfile
or letting default stand (pidfile is the standard approach) which will
make status work and make stop work.

> I am doing all this to get more familiar with pkgsrc and with rc.d
> system. I would be very grateful for your help and for your
> suggestions how to make that package better.

Welcome and please feel free to ask for an account on pkgsrc-wip.   It
is a shared place to do what you are doing, and easier for people to
just look there vs checking out a separate repo.

Hope this helps more than it confuses!