On Sat, 23 Oct 2021, Svante Signell wrote:
> > However, since you asked, PATH_MAX is set to 2048 in pidof.
This is twice as long as needed on all other systems, and
possibly too short on the Hurd.
> > Using get_current_dir_name() is not a valid way to do it as it is not
> > portable across C
On Sat, 2021-10-23 at 11:22 -0300, Jesse Smith wrote:
>
> This is getting bogged down in the weeds and not related to whether
> the readlink() patch works or not. The PATH_MAX usage is unrelated to
> the fix.
>
> However, since you asked, PATH_MAX is set to 2048 in pidof.
>
> Using
Jesse,
Thanks for this.
On Thu, Oct 21, 2021 at 02:51:36PM -0300, Jesse Smith wrote:
> Please give the attached patch a try and confirm it's working. It's
> working here for normal and zombie processes and it seems to be okay for
> uninterruptable sleep processes too, but I'd like to have
On Fri, 22 Oct 2021, Jesse Smith wrote:
> Hurd systems because there is explicitly a check for that and, if it's
> not defined, PATH_MAX is declared in the code. So this code is GNU Hurd
> safe.
To what value? (Spoiler: 1024 is wrong. All other values are also wrong.)
PATH_MAX does not exist on
On 2021-10-22 6:52 p.m., Svante Signell wrote:
> Hi Jesse,
>
> On Thu, 2021-10-21 at 14:51 -0300, Jesse Smith wrote:
>> Please give the attached patch a try and confirm it's working. It's
>> working here for normal and zombie processes and it seems to be okay
>> for uninterruptable sleep
Hi Jesse,
On Thu, 2021-10-21 at 14:51 -0300, Jesse Smith wrote:
> Please give the attached patch a try and confirm it's working. It's
> working here for normal and zombie processes and it seems to be okay
> for uninterruptable sleep processes too, but I'd like to have someone
> else confirm
On Thu, 21 Oct 2021, Jesse Smith wrote:
> "pidof -z " should return all matching processes,
> including those in the zombie state.
>
> The attached patch also cleans up some code we don't need as a result of
> this change and updates the man page.
>
> Please give the attached patch a try and
> The RedHat bug that was the similar issue to #719273 (i.e. that
> resulted in the behaviour of pidof being changed) took a slightly
> different approach -
> https://bugzilla.redhat.com/show_bug.cgi?id=138788 (patch is
> https://bugzilla.redhat.com/attachment.cgi?id=113650=diff );
> did that
Hi,
On 20/10/2021 15:29, Jesse Smith wrote:
Is there a reason for wanting to revert this behaviour instead of using
the "-z" flag on the command line? If you use pidof a lot and expect to
see processes that are in the uninterruptable sleep state then making an
alias of pidof='pidof -z' seems
On 2021-10-21 1:40 p.m., Matthew Vernon wrote:
> Hi,
>
> On 20/10/2021 15:29, Jesse Smith wrote:
>> Is there a reason for wanting to revert this behaviour instead of using
>> the "-z" flag on the command line? If you use pidof a lot and expect to
>> see processes that are in the uninterruptable
Jesse,
On Wed, Oct 20, 2021 at 11:29:23AM -0300, Jesse Smith wrote:
> Is there a reason for wanting to revert this behaviour instead of using
> the "-z" flag on the command line? If you use pidof a lot and expect to
> see processes that are in the uninterruptable sleep state then making an
>
Is there a reason for wanting to revert this behaviour instead of using
the "-z" flag on the command line? If you use pidof a lot and expect to
see processes that are in the uninterruptable sleep state then making an
alias of pidof='pidof -z' seems like a straight forward approach.
Reverting the
Tim,
Thanks
To me this seems a coherent argument for reverting this change.
What do other people think?
Mark
Package: sysvinit-utils
Version: 2.96-7
Followup-For: Bug #926896
The broken behaviour introduced by the fix to #719273 is the
assumption that all D state processes are stuck. D is indeed
"uninterruptable sleep", but uninterruptable in the sense that the
process can't respond to a signal until
The fix can be simple.
Currently processes in D and R state are ignored by pidof completely. But we
can use readlink() instead stat() in this case. Function readlink curretnly
used with -n option for some processes.
On Mon, 25 May 2020 14:06:42 +0200 (CEST) Thorsten Glaser
wrote:
> On Mon,
On Mon, 25 May 2020, Костик Покотиленко wrote:
> Should the fix be expected for Buster?
Definitely not.
If there is a fix, then you can hope for bullseye.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228
Hi.
Is the any thoughts on resolution?
Should the fix be expected for Buster?
Hi,
Костик Покотиленко wrote:
> > So from what I gather, this means that procps's pidof has the problem
> > described in this bug report?
> >
> > From my point of view the only way to solve this without reopening
> > #719273 is to add a switch which recognizes D processes or not. Or
> > adds some
> So from what I gather, this means that procps's pidof has the problem
> described in this bug report?
>
> From my point of view the only way to solve this without reopening
> #719273 is to add a switch which recognizes D processes or not. Or
> adds some kind of timeout.
>
>
I don't think so,
Костик Покотиленко wrote:
> Fedora ships pidof with procps-ng (procps on Debian) and does not have such
> problem.
>
> Debian ships pidof with sysvinit-utils which have this problem (skipping D
> and Z processes).
Костик Покотиленко wrote:
> This is regarding why this bug is not observed in
I wonder how many scripts have been silently broken
пт, 1 мая 2020 г. в 16:04, Костик Покотиленко :
> This is regarding why this bug is not observed in Stretch and earlier.
>
> D and Z skipping behaviour was introduced by
>
>
This is regarding why this bug is not observed in Stretch and earlier.
D and Z skipping behaviour was introduced by
http://git.savannah.nongnu.org/cgit/sysvinit.git/commit/src/killall5.c?id=1b659c8ebebd86be51095ab905293889a306ff01
to resolve
Caught this bug as well.
Discussing here
https://github.com/ClusterLabs/resource-agents/issues/1491
Fedora ships pidof with procps-ng (procps on Debian) and does not have such
problem.
Debian ships pidof with sysvinit-utils which have this problem (skipping D
and Z processes). There is no way
David,
I appreciate you doing some clean-up on the code and addressing the
zombie/sleeping process issue.
When I was applying the patch the part addressing the missing zombie
process did not apply and when I looked closer at the code it appears
that you are fixing is something that was already
I agree - I was just keeping the style consistent. I would argue that it was
totally unnecessary to do the check to all of these in the first place. I
would also argue that a function should be added which performs this clean up
so that it does not have to be repeated multiple times like it
On Mon, 4 Nov 2019, Hoyer, David wrote:
> if (p->statname) free(p->statname);
> - free(p->pathname);
> + if (p->pathname) free(p->pathname);
I realise it’s the preexisting style, but free(NULL) is defined and a nop.
bye,
//mirabilos
--
15:41⎜ Somebody
I am not seeing how it would have skipped the zombie processes in the past but
I also did not closely review that code.I did see in the comments that
skipping those processes was put in place because the stats would sometimes
fail. I would argue that this should have been handled at the
On 10/22/19 11:07 PM, Hoyer, David wrote:
> 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) ||
>
--Original Message-
From: Thorsten Glaser
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 un
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
> Jesse,
>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
for brief periods of time. Testing pidof
control: tags -1 +help
[ Adding to thread "apcupsd" Debian maintainer and "pidof" upstream
maintainer. ]
[2019-10-21 14:27] Martin von Wittich
> Am 20.10.19 um 20:59 schrieb Dmitry Bogatov:
> >
> > That sounds explainable. pidof() scans /proc directory, and it takes some
> > time for
Am 20.10.19 um 20:59 schrieb Dmitry Bogatov:
That sounds explainable. pidof() scans /proc directory, and it takes some
time for kernel to create entry there.
Hm, is there really a delay? I'm not very deep into kernel development,
but as far as I understand /proc, it isn't populated by the
[2019-10-17 15:04] Martin von Wittich
> I also just noticed this issue. We have a piece of code in our
> software that uses pidof to wait to apcupsd to start; I've reduced it
> to the following minimal working example:
> [...]
> There's always at least 4-6 empty "pidof:" lines at the
I also just noticed this issue. We have a piece of code in our software
that uses pidof to wait to apcupsd to start; I've reduced it to the
following minimal working example:
#!/bin/bash
set -eu
systemctl restart apcupsd
#sleep 1
echo "Connecting to ups, please wait..."
START=$SECONDS
Package: sysvinit-utils
Version: 2.93-8
Followup-For: Bug #926896
Hi Dmitry,
I tested 'dd if=/dev/urandom of=/dev/null' and it works.
Both when dd is running under normal user and as root.
And when pidof is running as normal user and as root.
(it also works when dd is run as root, and pidof as
control: tags -1 +moreinfo
[2019-04-11 20:55] Witold Baryluk
> Package: sysvinit-utils
> Version: 2.93-8
> Severity: important
>
> root@debian:~# echo; whoami; echo; ps aux | grep 'dd if'; echo; hd
> /proc/41344/cmdline ; echo; ls -l /proc/413
> 44/exe; echo; pidof dd || echo "Not found";
Package: sysvinit-utils
Version: 2.93-8
Severity: important
root@debian:~# echo; whoami; echo; ps aux | grep 'dd if'; echo; hd
/proc/41344/cmdline ; echo; ls -l /proc/41344/exe; echo; pidof dd || echo "Not
found"; echo; ls -l /proc/41344/exe
root
root 41344 2.0 0.0 217704 1960 pts/3
38 matches
Mail list logo
