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.