Hey, On 10.02.2018 15:56, Thomas Liske wrote: > Hi, > > Chris <fisch....@gmx.de> writes: >> Yes, it seems most processes of postfix are chrooted by default in >> Debian Stretch (plain install of Postfix via apt-get install postfix): > > I did install a vanilla Debian Stretch VM, setup an LXC container inside > (using Stretch again) and installed postfix inside the > container. Running needrestart inside of the container does *not* > detect any false positives on postfix. So it seems that your setup has > something special... > > On which linux distri and kernel are you running your LXC container? > From the kernel string it seems to be proxmox, isn't it?
Indeed this seems to be related and even the reason for the difference. The installation is a vanilla Debian Stretch with the Proxmox VE 5.1 from their repository "on top" running on a 4.13.13-5-pve Kernel. Luckily i had one single container running in "privileged" mode [1] (the others are "unprivileged" containers) and it seems this makes the difference: On all "unprivileged" container needrestart shows this behavior where the "privileged" doesn't falsely detect postfix and wazuh-agent as to be restarted. Any suggestion how to proceed with this? Closing this issue as it seems not directly related to Debian but to LXC / Proxmox? [1] https://pve.proxmox.com/wiki/Linux_Container#pct_settings > I assume there is something special in /proc/$PID/maps or the > /proc/$PID/map_files/$MADDR links are missing which are used by > needrestart. As fallback needrestart looks for /proc/$PID/root/$FILENAME > which fails for chrooted processes. > > > Regards, > Thomas Thanks, > > Needrestart looks for any executable mapped files > >> /usr/share/postfix/master.cf.dist used/installed by >> /var/lib/dpkg/info/postfix/postfix.postinst is e.g. chrooting the >> mentioned process: >> >> pickup unix n - y 60 1 pickup >> >>> Could you please post: >>> stat /usr/lib/postfix/sbin/pickup >> >> Sure: >> >> File: /usr/lib/postfix/sbin/pickup >> Size: 14408 Blocks: 32 IO Block: 4096 regular file >> Device: 715h/1813d Inode: 142070 Links: 1 >> Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2018-02-08 01:06:13.281395346 +0000 >> Modify: 2017-09-27 04:56:28.000000000 +0000 >> Change: 2018-01-26 14:10:42.474783916 +0000 >> Birth: - >> >>> stat /proc/25460/root/usr/lib/postfix/sbin/pickup >> >> the PIDs have changed here and are now: >> >> [main] #4262 uses non-existing /usr/lib/postfix/sbin/pickup >> [main] #4262 is a child of #478 >> >> stat: cannot stat '/proc/4262/root/usr/lib/postfix/sbin/pickup': No such >> file or directory >> >> and it seems the pickup is at: >> >> File: /proc/478/root/usr/lib/postfix/sbin/pickup >> Size: 14408 Blocks: 32 IO Block: 4096 regular file >> Device: 715h/1813d Inode: 142070 Links: 1 >> Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2018-02-08 01:06:13.281395346 +0000 >> Modify: 2017-09-27 04:56:28.000000000 +0000 >> Change: 2018-01-26 14:10:42.474783916 +0000 >> Birth: - >> >> I've also had a look at the previously mentioned dovecot which seems to >> be chrooted as well: >> >> "Login processes (imap-login, pop3-login) are chrooted by default into >> an empty non-writable directory." >> >> -> https://wiki.dovecot.org/Chrooting >> >> and indeed the same happening here: >> >> [main] #24776 uses non-existing /usr/lib/dovecot/imap-login >> [main] #24776 is a child of #13446 >> >> File: /usr/lib/dovecot/imap-login >> Size: 31336 Blocks: 64 IO Block: 4096 regular file >> Device: 70ah/1802d Inode: 920400 Links: 1 >> Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2018-02-08 13:49:54.190058675 +0100 >> Modify: 2017-06-30 21:01:28.000000000 +0200 >> Change: 2017-08-22 14:24:29.284898620 +0200 >> Birth: - >> >> >> stat: cannot stat '/proc/24776/root/usr/lib/dovecot/imap-login': No such >> file or directory >> >> >> File: /proc/13446/root/usr/lib/dovecot/imap-login >> Size: 31336 Blocks: 64 IO Block: 4096 regular file >> Device: 70ah/1802d Inode: 920400 Links: 1 >> Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) >> Access: 2018-02-08 13:49:54.190058675 +0100 >> Modify: 2017-06-30 21:01:28.000000000 +0200 >> Change: 2017-08-22 14:24:29.284898620 +0200 >> Birth: - >> >>> Regards, >>> Thomas >> >> Thanks >> >>>> [main] #338 exe => /var/ossec/bin/ossec-agentd >>>> [main] #338 is wazuh-agent.service >>>> [main] #430 exe => /usr/lib/postfix/sbin/master >>>> [main] #430 is postfix@-.service >>>> >>>> >>>> cat /proc/338/cgroup >>>> ------------- >>>> >>>> 12:cpuset:/ >>>> 11:hugetlb:/ >>>> 10:perf_event:/ >>>> 9:blkio:/ >>>> 8:net_cls,net_prio:/ >>>> 7:memory:/ >>>> 6:rdma:/ >>>> 5:cpu,cpuacct:/ >>>> 4:freezer:/ >>>> 3:pids:/system.slice/wazuh-agent.service >>>> 2:devices:/system.slice/wazuh-agent.service >>>> 1:name=systemd:/system.slice/wazuh-agent.service >>>> >>>> >>>> cat /proc/25460/cgroup >>>> ---------------------- >>>> >>>> 12:cpuset:/ >>>> 11:hugetlb:/ >>>> 10:perf_event:/ >>>> 9:blkio:/ >>>> 8:net_cls,net_prio:/ >>>> 7:memory:/ >>>> 6:rdma:/ >>>> 5:cpu,cpuacct:/ >>>> 4:freezer:/ >>>> 3:pids:/system.slice/system-postfix.slice/postfix@-.service >>>> 2:devices:/system.slice/system-postfix.slice >>>> 1:name=systemd:/system.slice/system-postfix.slice/postfix@-.service >>>> >>>> cat /proc/430/cgroup >>>> -------------------- >>>> >>>> 12:cpuset:/ >>>> 11:hugetlb:/ >>>> 10:perf_event:/ >>>> 9:blkio:/ >>>> 8:net_cls,net_prio:/ >>>> 7:memory:/ >>>> 6:rdma:/ >>>> 5:cpu,cpuacct:/ >>>> 4:freezer:/ >>>> 3:pids:/system.slice/system-postfix.slice/postfix@-.service >>>> 2:devices:/system.slice/system-postfix.slice >>>> 1:name=systemd:/system.slice/system-postfix.slice/postfix@-.service >>>> >>>> >>>> As you have mentioned cgroups i'm also getting the following output from >>>> the postfix services within the containers: >>>> >>>> Jan 28 15:51:51 example systemd[1]: postfix.service: Failed to reset >>>> devices.list: Operation not permitted >>>> Jan 28 15:51:51 example systemd[1]: postfix.service: Failed to set >>>> invocation ID on control group /system.slice/postfix.service, ignoring: >>>> Operation not permitted >>>> >>>> Not sure if this is related here. >>>> >>>>> Thanks, >>>>> Thomas >>>>> >>>>> >>>>> Chris <fisch....@gmx.de> writes: >>>>> >>>>>> Package: needrestart >>>>>> Version: 2.11-3 >>>>>> Severity: normal >>>>>> >>>>>> Dear Maintainer, >>>>>> >>>>>> having Postfix and the wazuh-agent package from [1] on a current Debian >>>>>> Stretch 9.3 running within an LXC container shows the following services >>>>>> as required for a restart even if the services, the container or the >>>>>> host was freshly restarted: >>>>>> >>>>>> postfix@-.service >>>>>> wazuh-agent.service >>>>>> >>>>>> Running needrestart with the -v parameter shows this output: >>>>>> >>>>>> [main] eval /etc/needrestart/needrestart.conf >>>>>> [main] needrestart v2.11 >>>>>> [main] running in root mode >>>>>> [Core] Using UI 'NeedRestart::UI::stdio'... >>>>>> [main] detected systemd >>>>>> [main] #372 uses non-existing /var/ossec/bin/ossec-agentd >>>>>> [main] #372 is not a child >>>>>> [main] #1047 uses non-existing /usr/lib/postfix/sbin/pickup >>>>>> [main] #1047 is a child of #438 >>>>>> [main] #372 exe => /var/ossec/bin/ossec-agentd >>>>>> [main] #372 is wazuh-agent.service >>>>>> [main] #438 exe => /usr/lib/postfix/sbin/master >>>>>> [main] #438 is postfix@-.service >>>>>> [Kernel] Linux: kernel release 4.13.13-5-pve, kernel version #1 SMP PVE >>>>>> 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) >>>>>> [Kernel/Linux] Did not find any linux images. >>>>>> Failed to retrieve available kernel versions. >>>>>> Restarting services... >>>>>> Services to be restarted: >>>>>> Restart «postfix@-.service»? [Ynas?] n >>>>>> Restart «wazuh-agent.service»? [Ynas?] n >>>>>> Services being skipped: >>>>>> systemctl restart postfix@-.service >>>>>> systemctl restart wazuh-agent.service >>>>>> No containers need to be restarted. >>>>>> No user sessions are running outdated binaries. >>>>>> >>>>>> The two mentioned binaries which doesn't exist according to needrestart >>>>>> output are there and accessible: >>>>>> >>>>>> ls -la /var/ossec/bin/ossec-agentd >>>>>> >>>>>> -rwxr-x--- 1 root root 528136 Dez 22 18:59 /var/ossec/bin/ossec-agentd >>>>>> >>>>>> ls -la /usr/lib/postfix/sbin/pickup >>>>>> >>>>>> -rwxr-xr-x 1 root root 14408 Sep 27 06:56 /usr/lib/postfix/sbin/pickup >>>>>> >>>>>> ls -la >>>>>> >>>>>> Not sure what causes this behavior. If there are any additional info i >>>>>> could / need to provide please let me know. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> [1] >>>>>> https://documentation.wazuh.com/current/installation-guide/installing-wazuh-agent/wazuh_agent_deb.html >>>>> >>>> >>> >
