Hello Paolo, thank for helping us finding the root cause of this problem!
Am Sun, 11 Aug 2019 10:12:36 +0200 schrieb Paolo Benvenuto <paolobe...@gmail.com>: > > I could imagine an issue with any kind of sandboxing configured on your > > host. > > What is a sandboxing? I am running a server, without any chroot or anything > similar Maybe "sandboxing" is not a very precise term. I wanted to refer to software, that restricts programs in any way. SELinux and apparmor are popular examples. Also the "seccomp" (Ithink) features configured in our systemd services definitions are such kind of sandboxing methods. Virtualization (like docker) can also enforce some restrictions on running processes. > > Maybe for a start: take a look at > > /etc/systemd/system/multi-user.target.wants/munin-node.service. There you > > can > > see the following execution parameters: > > PrivateDevices=false > > PrivateTmp=true > > ProtectHome=true > > ProtectSystem=full > > Please comment out all of them and check, whether the service still fails. > > (the above change modifies a file of the package - not a conffile - thus > > the change will get lost with the next package upgrade) > > I commented them out, now the service starts! Great - this is good to know! > > If this fixes the issue, then please find out, which of the setting is > > causing the failure. > > how?!?! You can stop the service again, remove some of the comments and try to start it again, until you find the minimal set of options, that need to be disabled for you. Afterwards we (munin packagers) can try to find out, under which circumstances this specific restriction could cause a problem. At the moment I suspect, that /var/log/munin is somehow symlinked on your system into /tmp or /run. But this is just a very wild guess. Thank you for your help! Cheers, Lars
