First of all I'm sorry for reporting this for an unsupported release, but I strongly believe this behaviour would not change on 11.1, diff does not show any related changes to /etc/rc.subr nor to /bin/ps
I encountered the issue in Smokeping which I reported in bug #221518. But that is not really Smokeping-related. It seems that this can happen to any process.
So what happen is that if a daemon's main process has nothing to do it might be swapped out and thus its details including command line won't be available to ps anymore. Smokeping in this case becomes just "(perl)".
The result is that check_pidfile can not recognize the process.
It is expected that ps (or any other tool that lists processes) does not show the command line if it is longer than the value of the kern.ps_arg_cache_limit sysctl (default: 256 bytes) and the process is swapped out.
A proper fix is not easy (this would involve not relying on the process list).
Apart from the workarounds mentioned in bug #221518, it is possible to increase the sysctl or move configuration data from the command line into a configuration file (if supported by the daemon).
Relaying on config parameters being in config file instead of command line is not much of a difference as way more is missing from `ps` output, mainly the primary program/script name. check_pidfile would have to relay only on $interpreter in such case.
As for the other solution I suggested in the original ticket, to use daemon(8), I'm not sure anymore if it would help. Daemon(8) might get swapped out too, unless it performs some checks periodically. But if it just waits for a signal, and I see a sigwait in wait_child function in source code, then this approach won't work.
(In reply to vegeta from comment #2)
Moving parameters to a configuration file helps because short command lines remain visible even if the process is swapped out.
That would probably require changes to smokeping itself. As far as I remember running it in slave mode is done without any config file, only via command line parameters.