Paul Ripke <stix%stix.id.au@localhost> writes: > Another thought: > Should _find_processes in /etc/rc.subr pay attention to a deamon's > configured user? I'm not quite ready to conclude that, but I agree that we should have a way that rc.d scripts for programs that use java can work correctly. > I run unifi from pkgsrc, which is java. I've also got a couple of > minecraft servers (also java) running to keep my son happy. I've just > discovered that the default rc.d script for unifi thinks that unifi > is running if any of the minecraft servers are running. The root cause here is the java attitude that people should invoke programs in java via a java command line that they have to semi-understand and carry from documentation, rather than having an executable -- even if a script that encapsulates this. But of course that's too hard to fix in general. I wonder how hard it would be to have /usr/pkg/bin/unifi that takes start and stop and has the long java command, and which then might be matchable via ps. > They both run under different users - should find_processes pay > attention to the configured user? Do we have a solution for java > servers and procname in rc.d? Your suggestion seems like a reasonable workaround. One could match on not just $command but also $command_args. While "start" is a traditional ccommand argument, the rest are really code that belongs in a program rather than command-line args, and this could make the match specific enough. Another possible approach is to add a "status" operator along with stop to unifi, but that is likely harder. A patch to improve this would be welcome for consideration.
Attachment:
signature.asc
Description: PGP signature