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. 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 foo.pid. 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. 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. Also you have some bizarre space characters \302\240 instead of a regular space in the PROVIDES line. Probably that's not the issue.
Attachment:
signature.asc
Description: PGP signature