Jesse,
With 93da64d13380b29fd330608493615f8877525494, I am not sure the change you
have upstream in
b70b2776eda9237e987b6d9e1185eb626eb75e2f is required.
Mark
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
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)
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
>
> 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
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
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
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
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
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.
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
+++
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
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
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. */
>
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",
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)
>
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
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)
>
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
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
```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 ->
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
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.
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.
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
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
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
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
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.
29 matches
Mail list logo
