Re: rc.d script to start gunicorn

[Frédéric Fauberteau <triaxx%NetBSD.org@localhost>]

Greg Troxel wrote:
> Frédéric Fauberteau <triaxx%NetBSD.org@localhost> writes:
>
> > I think the problem comes from the _find_processes function of
> > /etc/rc.subr since /srv/taiga/taiga-back/.venv/bin/python3.9 does not
> > match $command. Any idea on how handle this kind of daemon?
>
> (It's a bit hard to tell because your mail has munged formatting.)
>
> I don't understand why you are using _find_processes if there is a
> piffile.  In my view, the standard approach is  for a daemon to write
> pid to the pidfile, and for stop to send a signal to that pid, without
> messing with ps.

I don't directly use _find_processes(). I just run:
  $ service taiga stop
and I see by adding some echo commands in the /etc/rc.subr file that 
_find_processes() is called.

>   taiga is located in /usr/pkg/etc/rc.d
>   taiga not running? (check /var/run/taiga/gunicorn.log).
>
> Is it really printing that first line?

Yes.

> Are you really setting pifile to /var/run/taiga/gunicorn.log?  That is 
> a
> strange extension in terms of confusing humans, not that it should
> matter to scripts.  Normally it is foo.pid.

My bad. My mind wanted gunicorn.pid but my fingers decided differently.

> Is there a single pid in that file?  That's the way pid files are
> supposed to work.  Then when you send a signal (TERM?) to that single
> pid it is supposed to arrange to shut down the rest of the daemon's
> processes, if it is daemon that has multiple processes.

Yes. The file contains one pid <pid>. If I run:
  $ kill <pid>
then all the processes launched by gunicorn are stopped.

> I haven't dug into rc.subr but I would expect that if pidfile is set
> that is used and if it is not set then games are played with ps and
> command to try to find the process anyway.

About the check_pidfile() function, it is said in /etc/rc.subr:
  # Parses the first line of pidfile for a PID, and ensures
  # that the process is running and matches procname.
This function launches _find_processes() at its end. I assume here that 
$procname equals to $command.

> Also you have some bizarre space characters \302\240 instead of a
> regular space in the PROVIDES line.  Probably that's not the issue.

Thank you, I didn't see that.