pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rc.d script to start gunicorn

Greg Troxel wrote:
Frédéric Fauberteau <> 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?


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

My bad. My mind wanted 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.

Home | Main Index | Thread Index | Old Index