Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
Jesse, With 93da64d13380b29fd330608493615f8877525494, I am not sure the change you have upstream in b70b2776eda9237e987b6d9e1185eb626eb75e2f is required. Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
Control: tags -1 pending On Thu, Mar 30, 2023 at 08:19:57AM +0200, Markus Fischer wrote: > Nice find! And yes, I can confirm that it works for me too. Would be great > to see these fixes make it into bookworm. Thanks, I plan to upload this later today. Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
Nice find! And yes, I can confirm that it works for me too. Would be great to see these fixes make it into bookworm. - Markus Am 29.03.23 um 17:48 schrieb Mark Hindley: This single hunk on top of 3.06-2 fixes pidof following multiple symlinks for me when invoked as pidof $(which vi) Markus, can you confirm that works for you? Since it is a regression since bullseye, it seems a suitable targeted fix to attempt for bookworm. Thanks to everybody. Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
This single hunk on top of 3.06-2 fixes pidof following multiple symlinks for me
when invoked as
pidof $(which vi)
Markus, can you confirm that works for you?
Since it is a regression since bullseye, it seems a suitable targeted fix to
attempt for bookworm.
Thanks to everybody.
Mark
>From 93da64d13380b29fd330608493615f8877525494 Mon Sep 17 00:00:00 2001
From: Jesse
Date: Wed, 29 Mar 2023 10:34:45 -0300
Subject: [PATCH] Accepted patch from Mark Hindle which avoids clearing
realpath information in pidof when trying to find matching executables.
---
src/killall5.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/killall5.c b/src/killall5.c
index 9ab0782a..6f7528ad 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -740,8 +740,8 @@ PIDQ_HEAD *pidof(char *prog)
return NULL;
/* Try to stat the executable. */
+ memset(real_path, 0, sizeof(real_path));
if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) {
- memset(_path[0], 0, sizeof(real_path));
dostat++;
}
--
2.39.2
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
> > I think I have found the offending commit: > 0b695c7e0b1cac60ed77c56f224e296f023b652e uses memset *after* realpath which > wipes > the canonical resolved path. > > I suggest this fix as a starting point. > I'd agree. I was running into some situations where a symlink wasn't recognized and this corrects the behaviour for me. Committed this patch upstream. - Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
On Wed, Mar 29, 2023 at 08:37:00AM -0300, Jesse Smith wrote:
> > Given subsequent discussion, could we instead use canonicalize_file_name
> > or realpath here instead? That would give us the "correct" path without
> > pidof having to think hard about symlinks et al.
>
> I'm open to the possibility. I'm curious as to what you see as the pros
> vs cons of changing the approach used by pidof?
Markus' orginal report suggested this was a regression since Bullseye
sysvinit-utils | 2.96-7+deb11u1 | stable | amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
rather than a proposal to change behaviour.
I think I have found the offending commit:
0b695c7e0b1cac60ed77c56f224e296f023b652e uses memset *after* realpath which
wipes
the canonical resolved path.
I suggest this fix as a starting point.
Mark
>From 346cc4a8a91f908c8a57a16fb041c44809517183 Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Wed, 29 Mar 2023 13:57:24 +0100
Subject: [PATCH] Fix following of executable symlinks.
Fixes regression introduced in 0b695c7e0b1cac60ed77c56f224e296f023b652e
---
src/killall5.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/killall5.c b/src/killall5.c
index b0728fab..787c4226 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -739,10 +739,8 @@ PIDQ_HEAD *pidof(char *prog)
return NULL;
/* Try to stat the executable. */
- if ( (prog[0] == '/') && ( realpath(prog, real_path) ) ) {
- memset(_path[0], 0, sizeof(real_path));
+ if ( (prog[0] == '/') && ( realpath(prog, real_path) ) )
dostat++;
- }
/* Get basename of program. */
if ((s = strrchr(prog, '/')) == NULL)
--
2.39.2
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
On 29/03/2023 12:37, Jesse Smith wrote: Given subsequent discussion, could we instead use canonicalize_file_name or realpath here instead? That would give us the "correct" path without pidof having to think hard about symlinks et al. I'm open to the possibility. I'm curious as to what you see as the pros vs cons of changing the approach used by pidof? Broadly, I think there is an expectation that pidof $(which emacs) works on Debian (et al) systems where alternatives are in use (or other setups with >1 symlink), regardless of which user is running the emacs (WLOG). I think using realpath or canonicalize_file_name might simplify matters? But I've not gone poking through the code in detail, just this talk of more than one symlink confusing things made me think of these library functions. Perhaps as an aside, on my system with 3.06-2, I see different behaviour depending on the user running the binary: matthew@aragorn:~/junk$ ps waux | grep emacs root 3905 0.0 0.0 165344 3976 tty1 TMar06 0:00 emacs /etc/mumble-server.ini matthew 5149 0.0 1.0 453684 169224 ? Ss Feb11 61:26 emacs --daemon matthew 13119 0.0 0.3 214776 50076 pts/19 SFeb27 0:37 emacs accparse.py matthew@aragorn:~/junk$ pidof emacs 13119 5149 3905 matthew@aragorn:~/junk$ pidof $(which emacs) 3905 matthew@aragorn:~/junk$ pidof $(readlink -f $(which emacs)) 13119 5149 Here $(which emacs) -> /usr/bin/emacs -> /etc/alternatives/emacs -> /usr/bin/emacs-lucid So the root process is picked up with pidof /usr/bin/emacs and the user processes by pidof /usr/bin/emacs-lucid. pidof emacs picks up all three. In each case /proc/pid/exe is (a deleted version of) /usr/bin/emacs-lucid HTH, Matthew
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 24/03/2023 14:17, Jesse Smith wrote:
On 2023-03-24 6:44 a.m., Markus Fischer wrote:
I think I've figured it out. With the following patch I don't see the
unexpected behaviour anymore:
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -662,6 +662,7 @@ int readproc()
/* Try to stat the executable. */
snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
p->pathname = (char *)xmalloc(PATH_MAX);
+ memset(p->pathname, 0, PATH_MAX);
if (readlink(path, p->pathname, PATH_MAX) == -1) {
p->pathname = NULL;
}
This patch looks good to me. I'm adding it upstream.
Will run some more tests before publishing 3.07. And would appreciate it
if everyone following this issue could test too and provide feedback.
Given subsequent discussion, could we instead use canonicalize_file_name
or realpath here instead? That would give us the "correct" path without
pidof having to think hard about symlinks et al.
Matthew
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On Tue, 28 Mar 2023, Jesse Smith wrote: >pidof isn't going to chase down multiple layers of symbolic links. If I consider that a (not release-critical) bug that should be addressed by a Debian-local patch if upstream is hostile. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 2023-03-28 10:56 a.m., Markus Fischer wrote: > I did a few more tests of my own and didn't find any other issues. > > - Markus > Thank you. I'm planning to do the same and then publish an update to sysvinit.
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I did a few more tests of my own and didn't find any other issues.
- Markus
Am 24.03.23 um 15:17 schrieb Jesse Smith:
On 2023-03-24 6:44 a.m., Markus Fischer wrote:
I think I've figured it out. With the following patch I don't see the
unexpected behaviour anymore:
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -662,6 +662,7 @@ int readproc()
/* Try to stat the executable. */
snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
p->pathname = (char *)xmalloc(PATH_MAX);
+ memset(p->pathname, 0, PATH_MAX);
if (readlink(path, p->pathname, PATH_MAX) == -1) {
p->pathname = NULL;
}
This patch looks good to me. I'm adding it upstream.
Will run some more tests before publishing 3.07. And would appreciate it
if everyone following this issue could test too and provide feedback.
- Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 2023-03-28 10:40 a.m., Mark Hindley wrote: > On Thu, Mar 23, 2023 at 11:25:02AM -0300, Jesse Smith wrote: >>> $ ls -l $(which vi) >>> lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> >>> /etc/alternatives/vi >>> $ ls -l /etc/alternatives/vi >>> lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> >>> /usr/bin/vim.tiny >>> $ ls -l /usr/bin/vim.tiny >>> -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny >> >> Okay, yes, this makes sense. The symbolic links are making multiple >> jumps so it won't work. This is expected behaviour because there is no >> executable running called /usr/bin/vi or /etc/alternatives/vi. Running >> "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to >> /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't >> follow aliases or symbolic links with multiple hops and different names. > As Thorsten pointed out, multiple layers of symlinks is used in several places > in Debian, not least the alternatives system. > > Shouldn't src/killall.c readproc() run readlink(2) until it gets the canonical > executable path? > > Alternatively, if you really want to keep the behaviour change then pidof.8 > needs updating to reflect the new behaviour. > > I would say the manual page is already accurate. It says symbolic links to executables will return a match. This is true. It doesn't say symbolic links to symbolic links will return a match. Though perhaps this should be explicitly stated to clarify. I'll update the wording. pidof isn't going to chase down multiple layers of symbolic links. If the operator is dealing with situations like Debian's alternatives system then they should just use the real name of the executable (gcc vs cc, for example). Using a name that links to a name that links to another name is likely to bite people.
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On Thu, Mar 23, 2023 at 11:25:02AM -0300, Jesse Smith wrote: > > $ ls -l $(which vi) > > lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> > > /etc/alternatives/vi > > $ ls -l /etc/alternatives/vi > > lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> > > /usr/bin/vim.tiny > > $ ls -l /usr/bin/vim.tiny > > -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny > > > Okay, yes, this makes sense. The symbolic links are making multiple > jumps so it won't work. This is expected behaviour because there is no > executable running called /usr/bin/vi or /etc/alternatives/vi. Running > "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to > /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't > follow aliases or symbolic links with multiple hops and different names. As Thorsten pointed out, multiple layers of symlinks is used in several places in Debian, not least the alternatives system. Shouldn't src/killall.c readproc() run readlink(2) until it gets the canonical executable path? Alternatively, if you really want to keep the behaviour change then pidof.8 needs updating to reflect the new behaviour. Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 2023-03-24 6:44 a.m., Markus Fischer wrote:
> I think I've figured it out. With the following patch I don't see the
> unexpected behaviour anymore:
>
> --- a/src/killall5.c
> +++ b/src/killall5.c
> @@ -662,6 +662,7 @@ int readproc()
> /* Try to stat the executable. */
> snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
> p->pathname = (char *)xmalloc(PATH_MAX);
> + memset(p->pathname, 0, PATH_MAX);
> if (readlink(path, p->pathname, PATH_MAX) == -1) {
> p->pathname = NULL;
> }
>
This patch looks good to me. I'm adding it upstream.
Will run some more tests before publishing 3.07. And would appreciate it
if everyone following this issue could test too and provide feedback.
- Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I think I've figured it out. With the following patch I don't see the
unexpected behaviour anymore:
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -662,6 +662,7 @@ int readproc()
/* Try to stat the executable. */
snprintf(path, sizeof(path), "/proc/%s/exe", d->d_name);
p->pathname = (char *)xmalloc(PATH_MAX);
+ memset(p->pathname, 0, PATH_MAX);
if (readlink(path, p->pathname, PATH_MAX) == -1) {
p->pathname = NULL;
}
This patch gets rid of this uninitialised value warning I saw in valgrind:
==4158== Conditional jump or move depends on uninitialised value(s)
==4158==at 0x484748D: strcmp (vg_replace_strmem.c:924)
==4158==by 0x10A64F: pidof (killall5.c:797)
==4158==by 0x10B2EE: main_pidof (killall5.c:1031)
==4158==by 0x109700: main (killall5.c:1108)
==4158== Uninitialised value was created by a heap allocation
==4158==at 0x4840660: malloc (vg_replace_malloc.c:381)
==4158==by 0x10AD51: xmalloc (killall5.c:170)
==4158==by 0x10AD51: readproc (killall5.c:664)
==4158==by 0x10B2A0: main_pidof (killall5.c:1028)
==4158==by 0x109700: main (killall5.c:1108)
I compiled the killall5 binary with:
CFLAGS="-O2 -ggdb" make killall5
Am 23.03.23 um 16:25 schrieb Jesse Smith:
On 2023-03-23 12:04 p.m., Markus Fischer wrote:
I could also reproduce it with emacs. I've used emacs-gtk to avoid the
symlink.
```shell 1
$ emacs-gtk -nw -fn helvetica
```
```shell 2
$ ./pidof emacs-gtk
24727
$ ./pidof $(which emacs-gtk)
$ ls -l $(which emacs-gtk)
-rwxr-xr-x 1 root root 5294300 Mar 14 21:30 /usr/bin/emacs-gtk
```
This is interesting. Is there anything else you can share that might
shed light on why this happens while I can't get the same results? You
mentioned you're using two separate shells. Are they with the same user
account? Is there any PID hiding feature of Debian enabled? Does it
still happen if you run "pidof -z $(which emacs-gtk)"?
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 2023-03-23 12:04 p.m., Markus Fischer wrote: > I could also reproduce it with emacs. I've used emacs-gtk to avoid the > symlink. > > ```shell 1 > $ emacs-gtk -nw -fn helvetica > ``` > > ```shell 2 > $ ./pidof emacs-gtk > 24727 > $ ./pidof $(which emacs-gtk) > $ ls -l $(which emacs-gtk) > -rwxr-xr-x 1 root root 5294300 Mar 14 21:30 /usr/bin/emacs-gtk > ``` This is interesting. Is there anything else you can share that might shed light on why this happens while I can't get the same results? You mentioned you're using two separate shells. Are they with the same user account? Is there any PID hiding feature of Debian enabled? Does it still happen if you run "pidof -z $(which emacs-gtk)"?
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I could also reproduce it with emacs. I've used emacs-gtk to avoid the symlink. ```shell 1 $ emacs-gtk -nw -fn helvetica ``` ```shell 2 $ ./pidof emacs-gtk 24727 $ ./pidof $(which emacs-gtk) $ ls -l $(which emacs-gtk) -rwxr-xr-x 1 root root 5294300 Mar 14 21:30 /usr/bin/emacs-gtk ``` Am 23.03.23 um 15:50 schrieb Jesse Smith: On 2023-03-23 11:36 a.m., Markus Fischer wrote: Alright. Then there is still the issue with gdb, which is no symlink. A full example for that: ```shell 1 $ type gdb gdb is /usr/bin/gdb $ gdb --core=corefile ``` ```shell 2 $ ./pidof gdb 23125 $ ./pidof $(which gdb) $ ls -l $(which gdb) -rwxr-xr-x 1 root root 9904496 Feb 24 22:58 /usr/bin/gdb This one I have not been able to duplicate. Does it happen with any other programs which accept arguments or just gdb?
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 2023-03-23 11:36 a.m., Markus Fischer wrote: > Alright. Then there is still the issue with gdb, which is no symlink. > A full example for that: > > ```shell 1 > > $ type gdb > gdb is /usr/bin/gdb > $ gdb --core=corefile > > ``` > > ```shell 2 > > $ ./pidof gdb > 23125 > $ ./pidof $(which gdb) > $ ls -l $(which gdb) > -rwxr-xr-x 1 root root 9904496 Feb 24 22:58 /usr/bin/gdb > This one I have not been able to duplicate. Does it happen with any other programs which accept arguments or just gdb?
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
Alright. Then there is still the issue with gdb, which is no symlink. A full example for that: ```shell 1 $ type gdb gdb is /usr/bin/gdb $ gdb --core=corefile ``` ```shell 2 $ ./pidof gdb 23125 $ ./pidof $(which gdb) $ ls -l $(which gdb) -rwxr-xr-x 1 root root 9904496 Feb 24 22:58 /usr/bin/gdb ``` Am 23.03.23 um 15:25 schrieb Jesse Smith: On 2023-03-23 11:20 a.m., Markus Fischer wrote: ```shell 1 $ type vi vi is /usr/bin/vi $ vi ``` ```shell 2 $ cd ~/src/sysvinit-upstream/src/ $ ls -l pidof lrwxrwxrwx 1 ivanhoe ivanhoe 8 Mar 22 14:56 pidof -> killall5 $ ./pidof vi 21945 $ ./pidof $(which vi) $ ls -l $(which vi) lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> /etc/alternatives/vi $ ls -l /etc/alternatives/vi lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> /usr/bin/vim.tiny $ ls -l /usr/bin/vim.tiny -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny Okay, yes, this makes sense. The symbolic links are making multiple jumps so it won't work. This is expected behaviour because there is no executable running called /usr/bin/vi or /etc/alternatives/vi. Running "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't follow aliases or symbolic links with multiple hops and different names.
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 2023-03-23 11:20 a.m., Markus Fischer wrote: > ```shell 1 > > $ type vi > vi is /usr/bin/vi > $ vi > > ``` > > ```shell 2 > > $ cd ~/src/sysvinit-upstream/src/ > $ ls -l pidof > lrwxrwxrwx 1 ivanhoe ivanhoe 8 Mar 22 14:56 pidof -> killall5 > $ ./pidof vi > 21945 > $ ./pidof $(which vi) > $ ls -l $(which vi) > lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> > /etc/alternatives/vi > $ ls -l /etc/alternatives/vi > lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> > /usr/bin/vim.tiny > $ ls -l /usr/bin/vim.tiny > -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny Okay, yes, this makes sense. The symbolic links are making multiple jumps so it won't work. This is expected behaviour because there is no executable running called /usr/bin/vi or /etc/alternatives/vi. Running "pidof vi.tiny" would work. Or if /usr/bin/vi was a link to /usr/bin/vim.tiny then "pidof $(which vi)" would work. pidof won't follow aliases or symbolic links with multiple hops and different names.
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
```shell 1 $ type vi vi is /usr/bin/vi $ vi ``` ```shell 2 $ cd ~/src/sysvinit-upstream/src/ $ ls -l pidof lrwxrwxrwx 1 ivanhoe ivanhoe 8 Mar 22 14:56 pidof -> killall5 $ ./pidof vi 21945 $ ./pidof $(which vi) $ ls -l $(which vi) lrwxrwxrwx 1 root root 20 Jan 11 04:16 /usr/bin/vi -> /etc/alternatives/vi $ ls -l /etc/alternatives/vi lrwxrwxrwx 1 root root 17 Jan 11 04:16 /etc/alternatives/vi -> /usr/bin/vim.tiny $ ls -l /usr/bin/vim.tiny -rwxr-xr-x 1 root root 1713240 Jan 11 04:16 /usr/bin/vim.tiny ``` Am 23.03.23 um 15:03 schrieb Jesse Smith: Could you give a full example of pidof not detecting the vi process? I did all my testing as a regular user and both regular executables and symlinks are showing up in pidof process listings. With and without arguments. The only thing I can think of which would throw this off would be if the program being run was an alias. For example, if "vi" was an alias to "vim" rather than a symlink. On 2023-03-23 3:38 a.m., Markus Fischer wrote: I can confirm Mark's observation that "pidof $(which vi)" still does not work, at least when vi is running as normal user. However, when I run vi as root both pidof 3.06 and 3.07 work as expected. Also my 2nd issue (which might have gone unnoticed because I didn't cc anybody) is still open. I'm going to paste it here again: I just could reproduce another case where pidof with the argument being a full path to a binary doesn't return a pid. It is not related to the argument being a symlink. This time it seems to be related to the program having been started with arguments but I don't see the unexpected behaviour with just any arguments, just some. For example, when having gdb running with "gdb --core=corefile" "pidof $(which gdb)" does not return a pid but when I start gdb with "gdb --quiet" "pidof $(which gdb)" behaves as expected. I also noticed that as with vi above, when gdb was run as root "pidof $(which gdb)" works as expected with both 3.06 and 3.07. - Markus Am 22.03.23 um 16:38 schrieb Jesse Smith: On 2023-03-22 8:31 a.m., Mark Hindley wrote: Markus, Thanks for this. On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: Package: sysvinit-utils Version: 3.06-2 Severity: normal X-Debbugs-Cc: none Dear Maintainer, Passing the full path of a binary to the pidof command does not always return a pid although the process is running and the man page of the pidof command explicitly notes that it can be used that way. This might be related to the fact that all programs with which I tested this and which show this unexpected behaviour were symlinks (i.e., "which " returned a symlink). Yes, I just tried with vim.basic which is not a symlink on my system and both pidof vim.basic pidof $(which vim.basic) work as expected. However, on Debian Bullseye the behaviour is as I expected it. So this appears to be a change in behaviour. I suspect this is an inadvertent side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. Jesse, or was it intentional? I made a fix for this and have pushed it to the 3.07 branch of the SysV init repository. I'll publish a new version in a couple of days with this fix. There were some other changes to killall5 which are also in the queue, so this will fix a few issues. Would be great to have someone check the updated pidof and report if it's working okay for them too. - Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
Could you give a full example of pidof not detecting the vi process? I did all my testing as a regular user and both regular executables and symlinks are showing up in pidof process listings. With and without arguments. The only thing I can think of which would throw this off would be if the program being run was an alias. For example, if "vi" was an alias to "vim" rather than a symlink. On 2023-03-23 3:38 a.m., Markus Fischer wrote: > I can confirm Mark's observation that "pidof $(which vi)" still does > not work, at least when vi is running as normal user. However, when I > run vi as root both pidof 3.06 and 3.07 work as expected. > > Also my 2nd issue (which might have gone unnoticed because I didn't cc > anybody) is still open. I'm going to paste it here again: > >> I just could reproduce another case where pidof with the argument being >> a full path to a binary doesn't return a pid. It is not related to the >> argument being a symlink. >> >> This time it seems to be related to the program having been started with >> arguments but I don't see the unexpected behaviour with just any >> arguments, just some. >> >> For example, when having gdb running with "gdb --core=corefile" "pidof >> $(which gdb)" does not return a pid but when I start gdb with "gdb >> --quiet" "pidof $(which gdb)" behaves as expected. > > I also noticed that as with vi above, when gdb was run as root "pidof > $(which gdb)" works as expected with both 3.06 and 3.07. > > - Markus > > > Am 22.03.23 um 16:38 schrieb Jesse Smith: >> On 2023-03-22 8:31 a.m., Mark Hindley wrote: >>> Markus, >>> >>> Thanks for this. >>> >>> On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: Package: sysvinit-utils Version: 3.06-2 Severity: normal X-Debbugs-Cc: none Dear Maintainer, Passing the full path of a binary to the pidof command does not always return a pid although the process is running and the man page of the pidof command explicitly notes that it can be used that way. This might be related to the fact that all programs with which I tested this and which show this unexpected behaviour were symlinks (i.e., "which " returned a symlink). >>> Yes, I just tried with vim.basic which is not a symlink on my system >>> and both >>> >>> pidof vim.basic >>> pidof $(which vim.basic) >>> >>> work as expected. >>> However, on Debian Bullseye the behaviour is as I expected it. >>> So this appears to be a change in behaviour. I suspect this is an >>> inadvertent >>> side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. >>> >>> Jesse, or was it intentional? >>> >> >> I made a fix for this and have pushed it to the 3.07 branch of the SysV >> init repository. I'll publish a new version in a couple of days with >> this fix. There were some other changes to killall5 which are also in >> the queue, so this will fix a few issues. >> >> Would be great to have someone check the updated pidof and report if >> it's working okay for them too. >> >> - Jesse >>
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I can confirm Mark's observation that "pidof $(which vi)" still does not work, at least when vi is running as normal user. However, when I run vi as root both pidof 3.06 and 3.07 work as expected. Also my 2nd issue (which might have gone unnoticed because I didn't cc anybody) is still open. I'm going to paste it here again: I just could reproduce another case where pidof with the argument being a full path to a binary doesn't return a pid. It is not related to the argument being a symlink. This time it seems to be related to the program having been started with arguments but I don't see the unexpected behaviour with just any arguments, just some. For example, when having gdb running with "gdb --core=corefile" "pidof $(which gdb)" does not return a pid but when I start gdb with "gdb --quiet" "pidof $(which gdb)" behaves as expected. I also noticed that as with vi above, when gdb was run as root "pidof $(which gdb)" works as expected with both 3.06 and 3.07. - Markus Am 22.03.23 um 16:38 schrieb Jesse Smith: On 2023-03-22 8:31 a.m., Mark Hindley wrote: Markus, Thanks for this. On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: Package: sysvinit-utils Version: 3.06-2 Severity: normal X-Debbugs-Cc: none Dear Maintainer, Passing the full path of a binary to the pidof command does not always return a pid although the process is running and the man page of the pidof command explicitly notes that it can be used that way. This might be related to the fact that all programs with which I tested this and which show this unexpected behaviour were symlinks (i.e., "which " returned a symlink). Yes, I just tried with vim.basic which is not a symlink on my system and both pidof vim.basic pidof $(which vim.basic) work as expected. However, on Debian Bullseye the behaviour is as I expected it. So this appears to be a change in behaviour. I suspect this is an inadvertent side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. Jesse, or was it intentional? I made a fix for this and have pushed it to the 3.07 branch of the SysV init repository. I'll publish a new version in a couple of days with this fix. There were some other changes to killall5 which are also in the queue, so this will fix a few issues. Would be great to have someone check the updated pidof and report if it's working okay for them too. - Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program
Control: tags -1 upstream
Jesse,
Thanks for your quick work on this.
On Wed, Mar 22, 2023 at 12:40:43PM -0300, Jesse Smith wrote:
> This has been fixed upstream for the upcoming sysvinit 3.07. Would be
> great to get some people testing it before we do an official reelase of
> the 3.07 branch.
>
> The updated pidof will now return an PID matches for a corresponding
> executable or symbolic link. In other words, if /tmp/sleep is a symbolic
> link to /usr/bin/sleep, then it doesn't matter which path name we use,
> pidof will recognize both names go to the same real program and print
> its PID.
I have just done a local build of 3.06 with a cherry pick of just this hunk of
b70b2776
diff --git a/src/killall5.c b/src/killall5.c
index 992ce3e1..75750d32 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -763,6 +763,11 @@ PIDQ_HEAD *pidof(char *prog)
add_pid_to_q(q, p);
foundone++;
}
+else if ( (p->argv0) && (! strcmp(p->argv0, prog) ) )
+{
+add_pid_to_q(q, p);
+foundone++;
+}
}
}
--
2.39.2
The patched version still fails to find a running vi process when run as
pidof $(which vi)
Is that because there are 2 layers of symlinks?
/usr/bin/vi -> /etc/alternatives/vi -> /usr/bin/vim.basic
Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 2023-03-22 8:31 a.m., Mark Hindley wrote: > Markus, > > Thanks for this. > > On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: >> Package: sysvinit-utils >> Version: 3.06-2 >> Severity: normal >> X-Debbugs-Cc: none >> >> Dear Maintainer, >> >> Passing the full path of a binary to the pidof command does not always >> return a pid although the process is running and the man page of the >> pidof command explicitly notes that it can be used that way. >> >> This might be related to the fact that all programs with which I tested >> this and which show this unexpected behaviour were symlinks (i.e., >> "which " returned a symlink). > Yes, I just tried with vim.basic which is not a symlink on my system and both > > pidof vim.basic > pidof $(which vim.basic) > > work as expected. > >> However, on Debian Bullseye the >> behaviour is as I expected it. > So this appears to be a change in behaviour. I suspect this is an inadvertent > side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. > > Jesse, or was it intentional? > I made a fix for this and have pushed it to the 3.07 branch of the SysV init repository. I'll publish a new version in a couple of days with this fix. There were some other changes to killall5 which are also in the queue, so this will fix a few issues. Would be great to have someone check the updated pidof and report if it's working okay for them too. - Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
I just could reproduce another case where pidof with the argument being a full path to a binary doesn't return a pid. It is not related to the argument being a symlink. This time it seems to be related to the program having been started with arguments but I don't see the unexpected behaviour with just any arguments, just some. For example, when having gdb running with "gdb --core=corefile" "pidof $(which gdb)" does not return a pid but when I start gdb with "gdb --quiet" "pidof $(which gdb)" behaves as expected.
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
On 2023-03-22 8:31 a.m., Mark Hindley wrote: > Markus, > > Thanks for this. > > On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: >> Package: sysvinit-utils >> Version: 3.06-2 >> Severity: normal >> X-Debbugs-Cc: none >> >> Dear Maintainer, >> >> Passing the full path of a binary to the pidof command does not always >> return a pid although the process is running and the man page of the >> pidof command explicitly notes that it can be used that way. >> >> This might be related to the fact that all programs with which I tested >> this and which show this unexpected behaviour were symlinks (i.e., >> "which " returned a symlink). > Yes, I just tried with vim.basic which is not a symlink on my system and both > > pidof vim.basic > pidof $(which vim.basic) > > work as expected. > >> However, on Debian Bullseye the >> behaviour is as I expected it. > So this appears to be a change in behaviour. I suspect this is an inadvertent > side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. > > Jesse, or was it intentional? > It's a side-effect of the attempt to make pidof less prone to hanging when checking sleeping processes and zombies. I'll look into it as the symlink should probably work, or at least we should issue a warning. - Jesse
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
Markus, Thanks for this. On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote: > Package: sysvinit-utils > Version: 3.06-2 > Severity: normal > X-Debbugs-Cc: none > > Dear Maintainer, > > Passing the full path of a binary to the pidof command does not always > return a pid although the process is running and the man page of the > pidof command explicitly notes that it can be used that way. > > This might be related to the fact that all programs with which I tested > this and which show this unexpected behaviour were symlinks (i.e., > "which " returned a symlink). Yes, I just tried with vim.basic which is not a symlink on my system and both pidof vim.basic pidof $(which vim.basic) work as expected. > However, on Debian Bullseye the > behaviour is as I expected it. So this appears to be a change in behaviour. I suspect this is an inadvertent side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e. Jesse, or was it intentional? Thanks Mark
Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program
Package: sysvinit-utils Version: 3.06-2 Severity: normal X-Debbugs-Cc: none Dear Maintainer, Passing the full path of a binary to the pidof command does not always return a pid although the process is running and the man page of the pidof command explicitly notes that it can be used that way. This might be related to the fact that all programs with which I tested this and which show this unexpected behaviour were symlinks (i.e., "which " returned a symlink). However, on Debian Bullseye the behaviour is as I expected it. Steps to reproduce: * start vi * in another shell run "pidof vi" and "pidof $(which vi)" Result: The first pidof invocation correctly returns a pid but the second invocation does not. Expected result: Both invocations of pidof should return a pid. -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 6.1.0-6-686-pae (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sysvinit-utils depends on: ii libc6 2.36-8 sysvinit-utils recommends no packages. sysvinit-utils suggests no packages. -- no debconf information
