| Summary: | sys-process/procps-3.3.9: pidof does not match "comm" field of /proc/$PID/stat file (like pidof from sys-apps/sysvinit does) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sergey Popov <pinkbyte> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | idarktemplar, marat, tho_public |
| Priority: | Normal | Keywords: | REGRESSION |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://gitlab.com/procps-ng/procps/issues/4 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 510316 | ||
From the same forum thread: the usage of "pidof" comes from /etc/acpi/actions/powerbtn.sh, which belongs to sys-power/acpid-2.0.22:
# A list of power management system process names.
PMS="gnome-power-manager kpowersave xfce4-power-manager"
PMS="$PMS guidance-power-manager.py dalston-power-applet"
# If one of those is running or any of several others,
if pidof x $PMS > /dev/null ||
( test "$XUSER" != "" && pidof dcopserver > /dev/null && test -x /usr/bin/dcop && /usr/bin/dcop --user $XUSER kded kded loadedModules | grep -q klaptopdaemon) ||
( test "$XUSER" != "" && test -x /usr/bin/qdbus && test -r /proc/$(pidof kded4)/environ && su - $XUSER -c "eval $(echo -n 'export '; cat /proc/$(pidof kded4)/environ |tr '\0' '\n'|grep DBUS_SESSION_BUS_ADDRESS); qdbus org.kde.kded" | grep -q powerdevil) ; then
# Get out as the power manager that is running will take care of things.
exit
fi
If this is not a bug in sys-process/procps-3.3.9, please reassign to sys-power/acpid-2.0.22 and retitle to "broken usage of pidof".
*** Bug 510970 has been marked as a duplicate of this bug. *** we need some more details here like the actual `ps aux` output i'm running kde4, but `pidof kde4` shows nothing when using procps or sysvinit (In reply to SpanKY from comment #3) > i'm running kde4, but `pidof kde4` shows nothing when using procps or > sysvinit It does not return anything using newer procps for obvious reasons. Process name is not 'kde4', it's 'kded4' > we need some more details here like the actual `ps aux` output pinkbyte@oas1 ~ $ ps aux | grep kded4 pinkbyte 31078 0.0 1.5 1013940 61632 ? Sl 09:49 0:00 kdeinit4: kded4 [kdeinit] i've moved it upstream |
In configuration like: =sys-process/procps-3.3.9 =sys-apps/sysvinit-2.88-r7 =sys-apps/util-linux-2.24.1-r2 pidof kded4 on system with running KDE shows nothing. In configuration like: =sys-process/procps-3.3.8-r2 =sys-apps/sysvinit-2.88-r4 =sys-apps/util-linux-2.22.2 pidof kded4 shows PID properly. Probably it is because how new pidof parses cmdline output, strace shows: stat("/proc/17873", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 open("/proc/17873/stat", O_RDONLY) = 4 read(4, "17873 (kded4) S 1 17870 17870 0 "..., 1024) = 336 close(4) = 0 open("/proc/17873/cmdline", O_RDONLY) = 4 read(4, "kdeinit4: kded4 [kdeinit]\0\0\0\0\0\0\0"..., 2047) = 35 close(4) = 0 readlink("/proc/17873/exe", "/usr/bin/kdeinit4", 1023) = 17 This bug was discovered by user iVS from linux.org.ru forum, strace submitted by user AEP. Please, clarify if this behaviour is bug or a feature ;-)