We have also been experiencing this problem since moving to Buster. We never
saw this with Jessie. I believe it comes down to the following code in
readproc:
if ( (strchr(process_status, 'D') != NULL) ||
(strchr(process_status, 'Z') != NULL) ){
/* Ignore zombie processes or processes in
disk sleep, as attempts
to access the stats of these will
sometimes fail. */
if (p->argv0) free(p->argv0);
if (p->argv1) free(p->argv1);
if (p->statname) free(p->statname);
free(p);
continue;
}
Our scenario is similar although not with the same process that is described
below. It seems like this makes pidof not as effective for finding the pid
of a process if D states are skipped. Are there alternatives to pidof? (BTW
the -z option does not appear to help since this code snippet will remove it
from the process list).
-----Original Message-----
From: Thorsten Glaser <t.gla...@tarent.de>
Sent: Tuesday, October 22, 2019 6:26 PM
To: jsm...@resonatingmedia.com; 926...@bugs.debian.org
Subject: Bug#926896: sysvinit-utils: pidof is unreliable
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
On Tue, 22 Oct 2019, Jesse Smith wrote:
> > any ideas how it could be possible for process to be discovered by
> > ps(1), but not pidof(1)?
> I can think of a few possibilities, though they seem unlikely. One is
> that the process could be crashing and restarting, making it a zombie
or in D state, doing disc I/O… more likely even.
> for brief periods of time. Testing pidof with the "-z" flag would fill
> in the "holes" in the test output if that theory is correct.
Also: start-stop-daemon --status should probably be used ipv pidof.
(Even its manpage says so.)
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID
(VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
--
To unsubscribe, send mail to 926896-unsubscr...@bugs.debian.org.
