JP Vossen via plug on 7 Jun 2024 13:07:42 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
[PLUG] root "pkill: killing pid * failed: Operation not permitted" |
What could cause "pkill: killing pid * failed: Operation not permitted" *when run by root*? After patching and reboots the other day I started getting daily Anacron emails from Logrotate on most (but not all) of 50+ VMs saying: ``` /etc/cron.daily/logrotate: pkill: killing pid NNN failed: Operation not permitted ``` The culprit is the (quite horrible, but mandatory) Crowdstrike `falcon-agent` service, running from the stock vendor RPM that has not changed since April, and we've had patching reboots since then. The really confusing thing is that *most* of them are doing this, but *not* all, and I can't find any differences! The 50+ VMs are a mix of (quite horrible, but mandatory) Oracle Linux 7.9 (EoL soon, thus migrating) and 8.10, but the problem doesn't follow the distro. Also, a few of the ones that complained on Wed did not complain on Thu, so they "fixed" themselves? When I manually run the relevant line from `/etc/logrotate.d/falcon-sensor` *as root*, it either silently works or fails with the error above, according to whether I get the Anacron emails or not. So it's not that `/usr/bin/pkill -HUP falcon-sensor` is a problem, and it is running as root. It just...sometimes works and sometimes doesn't. The `falcon-sensor` process itself is running as root, as is the parent `falcond`. Restarting via `systemctl restart falcon-sensor` doesn't help, neither does a stop then start. Every VM has the same `falcon-sensor-7.01.0-15604.el7.x86_64` or `falcon-sensor-7.01.0-15604.el8.x86_64` and both vendor RPMs have identical *stock* `/etc/logrotate.d/falcon-sensor` and `/usr/lib/systemd/system/falcon-sensor.service` files. `/usr/bin/pkill` is also the same on working and broken servers, and SELinux is disabled. They all have the same kernel (current for either OEL-7 or 8) and it is *not* UEK (the Oracle Unusable Enterprise Kernel that always ends in tears). They all have plenty of free disk space. This is over-simplified (and skipping some related nodes), but I have 5 groups of 8 identical "agent" VMs, and for 4 groups 7 fail and 1 works. The 5th group only had 3 bad out of 8, then that "fixed" itself. Clues? Thanks, JP -- ------------------------------------------------------------------- JP Vossen, CISSP | http://www.jpsdomain.org/ | http://bashcookbook.com/ ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug