Bug 1177819
| Summary: | systemd inside Parallels Virtuozzo VM: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Peter Bieringer <pb> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | qe-baseos-daemons |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | janfrode, jorti, kolyshkin, lnykryn, nigel, perl-devel, steve, systemd-maint-list, vanmeeuwen+fedora |
| Target Milestone: | rc | ||
| Target Release: | 7.1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-12-14 12:30:20 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Peter Bieringer
2014-12-30 16:51:32 UTC
Update on that issue: it will not happen using a VM inside VirtualBox...also the shown URL points to a Strato vServer (which is also here the case). Can it be that the issue is cased by Parallels Virtuozzo? # uname -r -v -m 3.10.0-042stab092.3 #1 SMP Sun Jul 20 13:27:24 MSK 2014 x86_64 Also a grep -r shows that amavisd is currently the only one which defines in systemd config the "NoNewPrivileges" parameter - no other service does this so far. # LANG=C grep NoNewPrivileges /usr/lib/systemd/* -r /usr/lib/systemd/system/amavisd-clean-tmp.service:NoNewPrivileges=true /usr/lib/systemd/system/amavisd.service:NoNewPrivileges=true /usr/lib/systemd/system/amavisd-clean-quarantine.service:NoNewPrivileges=true Binary file /usr/lib/systemd/systemd matches BTW: also the amavisd-clean-tmp.service is claiming: Jan 3 18:23:01 *** tmpwatch[720]: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/tmpwatch: Invalid argument Jan 3 18:23:01 *** tmpwatch[719]: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/tmpwatch: Invalid argument Woraround so far: disabling this NoNewPrivileges option: # perl -pi.orig -e 's/^(NoNewPrivileges=)true/\1false/' /usr/lib/systemd/system/amavisd-clean-quarantine.service # perl -pi.orig -e 's/^(NoNewPrivileges=)true/\1false/' /usr/lib/systemd/system/amavisd-clean-tmp.service # perl -pi.orig -e 's/^(NoNewPrivileges=)true/\1false/' /usr/lib/systemd/system/amavisd.service # systemctl daemon-reload BTW: tried to use SecureBits instead, but this is also causing an error amavisd[2941]: Failed at step SECUREBITS spawning /usr/sbin/amavisd: Operation not permitted Assigned this bug now to systemd, looks like Parallels Virtuozzo blocks related prctl calls (PR_SET_NO_NEW_PRIVS, PR_SET_SECUREBITS) (found in systemd src/core/execute.c) # rpm -q systemd systemd-208-11.el7_0.5.x86_64 Looks like systemd should change its behavior to a "softfail/ignore" in case of prctl calls fail and the reason is the underlying virtualization/container platform. For the record, I am having a similar problem, however I'm using CentOS 7.1 here under OpenVZ. An identical setup (as far as I can tell) works fine under CentOS 6.6. Jun 9 02:10:38 gin systemd: Starting Amavisd-new is an interface between MTA and content checkers.... Jun 9 02:10:38 gin systemd: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument Jun 9 02:10:38 gin systemd: amavisd.service: control process exited, code=exited status=227 Jun 9 02:10:38 gin systemd: Failed to start Amavisd-new is an interface between MTA and content checkers.. Yet if I run from the command line, it works just fine. I've seen quite a few reports and no actual explanations, other than this which is really a work around. I'd be willing to try some other solutions other than a work around. amavisd-new-2.10.1-4.el7.noarch Can you please retest with this test package https://copr.fedoraproject.org/coprs/lnykryn/systemd/ ? I installed the package however my VPS fails to boot. Looking at the serial console... # ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 12:01 ? 00:00:00 init -z root 2 1 0 12:01 ? 00:00:00 [kthreadd/2374] root 3 2 0 12:01 ? 00:00:00 [khelper/2374] root 70 1 0 12:01 ? 00:00:00 vzctl: pts/0 root 71 70 0 12:01 pts/0 00:00:00 -bash root 98 71 0 12:02 pts/0 00:00:00 ps -ef If I try to run any systemctl commands I get Failed to get D-Bus connection: No such file or directory So I have a pretty much borked system right now. Keep in mind I'm trying this on an openvz container that I have little/no control over. Oh, I did try starting systemd-udevd manually but is just hangs after "starting version 209". So it looks like a reinstall. In fact, there's so many problems with what I'm trying to do right now, maybe I'll stick with 6.6. Uh, this is really weird. > root 1 0 0 12:01 ? 00:00:00 init -z there should be something like: root 1 0 0 08:53 ? 00:00:01 /usr/lib/systemd/systemd --switc > "starting version 209" we are rebasing form 208 to 219 > I'll stick with 6.6. THis is version of what? I was not able to reproduce the issue reported, using these: # rpm -q systemd amavisd-new systemd-208-11.el7_0.5.x86_64 amavisd-new-2.10.1-4.el7.noarch # uname -a Linux efgh.com 2.6.32-042stab109.4 #1 SMP Fri May 8 15:31:07 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux Note that your OpenVZ/VZ kernel (042stab092.3) is pretty old (about 1 year old). Maybe this is the reason why it's failing. Also, try to run yum update inside your container. Reproduced under the 042stab092.3 kernel so it looks like a problem of the old kernel. Please update your kernel (or ask your service provider to do so). Running 1 year old kernel in production is not acceptable for many reasons. To the bug assignee -- I would close the bug as INVALID Meanwhile the underlying Virtuozzo platform got an update to 3.10.0-042stab111.12 and installing the amavisd-new update released last days runs without any changes (while still having defined: NoNewPrivileges=true) => issue can be closed |