most, if not all of my systemd-units on a dozen of servers using constructs like below to make the whole tree /var/lib readonly and the needed subfolder RW which is now broken in Fedora 21 and kills all my setups that is a *major regression* because this affects a lot of customized, non-packaged systemd units all over the place ____________________________ ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/mysql 150120 13:44:01 [ERROR] Can't start server : Bind on unix socket: Read-only file system 150120 13:44:01 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysqld_dbmail.sock ?
What systemd version? I cannot reproduce this with either systemd-216-14.fc21 or systemd-216-16.fc21 from updates. Do you have a minimal reproducer?
You posted to two mailing lists in addition to the bugtracker, but let's try this focued here. > after upgrade to Fedora 21 with new systemd namespaces like below > no longer works which breaks *all my systemd-units* Does this mean that it worked in F20 and it breaks after upgrade to F21?
it worked even in F18 and F19 systemd-216-14.fc21.x86_64 just look at the two commented lines below and the same affects any other service here where i use ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/<programname> from spamassassin, clamd to httpd and especially for httpd i have some currently still on F20 running appliances where the whole document root is a "ReadOnlyDirectories" namespace and the upload, logs and temp-folder are "ReadWriteDirectories" which would also break _____________________________________________________ [root@testserver:/etc/systemd/system]$ cat /usr/lib/systemd/system/mysqld-dbmail.service [Unit] Description=MySQL DBMail-Database Before=postfix.service dovecot.service dbmail-imapd.service dbmail-lmtpd.service dbmail-pop3d.service dbmail-timsieved.service dbmail-postfix-policyd.service [Service] Type=simple User=mysql Group=mysql NoNewPrivileges=yes ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my-dbmail.cnf --pid-file=/run/mysqld/mysqld_dbmail.pid ExecStartPost=/usr/libexec/mysqld-dbmail-wait-ready $MAINPID Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutSec=300 LimitNOFILE=infinity LimitMEMLOCK=infinity OOMScoreAdjust=-1000 SysVStartPriority=64 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_DAC_OVERRIDE CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/proc ReadOnlyDirectories=/sys # ReadOnlyDirectories=/var/lib # ReadWriteDirectories=/var/lib/mysql InaccessibleDirectories=/boot InaccessibleDirectories=/home InaccessibleDirectories=/root InaccessibleDirectories=/media InaccessibleDirectories=/usr/local/scripts InaccessibleDirectories=/var/lib/dbus InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/systemd InaccessibleDirectories=/var/lib/yum InaccessibleDirectories=/var/spool InaccessibleDirectories=/run/dbus InaccessibleDirectories=/run/lock InaccessibleDirectories=/run/mount InaccessibleDirectories=/run/systemd/generator InaccessibleDirectories=/run/systemd/system InaccessibleDirectories=/run/systemd/users InaccessibleDirectories=/run/udev InaccessibleDirectories=/run/user [Install] WantedBy=multi-user.target
my god - restrict /proc and /sys as readonly seems to break the namespaces on Fedora 21 - why does that setting meant for the mainpid affect also PID1 now? ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr # ReadOnlyDirectories=/proc # ReadOnlyDirectories=/sys ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/mysql
systemd-216 is definitly completly broken why are "ExecStartPre" in combination with "PermissionsStartOnly=yes" affected from the "ReadOnlyDirectories", keep in mind that the systemd-unit below works also with F19/F20 all the time as expected Jan 21 03:37:34 testserver chown: /usr/bin/chown: der Eigentümer von „/var/lib/mailgraph/mailgraph.rrd“ wird geändert: Das Dateisystem ist nur lesbar Jan 21 03:37:34 testserver chown: /usr/bin/chown: der Eigentümer von „/var/lib/mailgraph/mailgraph_virus.rrd“ wird geändert: Das Dateisystem ist nur lesbar Jan 21 03:37:34 testserver chown: /usr/bin/chown: der Eigentümer von „/var/lib/mailgraph/“ wird geändert: Das Dateisystem ist nur lesbar ________________________________________________________________ [root@testserver:~]$ cat /etc/systemd/system/mailgraph.service [Unit] Description=Mailgraph [Service] Type=simple PrivateTmp=yes PrivateDevices=yes PermissionsStartOnly=yes ExecStartPre=/usr/bin/chown -R nobody:root /var/lib/mailgraph/ ExecStartPre=/usr/bin/chown nobody:apache /var/cache/mailgraph/ ExecStartPre=/usr/bin/chmod 0770 /var/cache/mailgraph/ ExecStart=/usr/bin/perl -w /usr/sbin/mailgraph -l /var/log/maillog --daemon-rrd=/var/lib/mailgraph Restart=always RestartSec=1 TimeoutSec=15 Nice=19 IOSchedulingClass=3 CapabilityBoundingSet=CAP_IPC_LOCK User=nobody Group=root ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr # ReadOnlyDirectories=/proc # ReadOnlyDirectories=/sys ReadOnlyDirectories=/var ReadWriteDirectories=/var/lib/mailgraph ReadWriteDirectories=/var/cache/mailgraph InaccessibleDirectories=/boot InaccessibleDirectories=/home InaccessibleDirectories=/root InaccessibleDirectories=/media InaccessibleDirectories=/run/console InaccessibleDirectories=/run/dbus InaccessibleDirectories=/run/lock InaccessibleDirectories=/run/mount InaccessibleDirectories=/run/systemd/generator InaccessibleDirectories=/run/systemd/system InaccessibleDirectories=/run/systemd/users InaccessibleDirectories=/run/udev InaccessibleDirectories=/run/user InaccessibleDirectories=/usr/local/scripts InaccessibleDirectories=/var/lib/dbus InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/systemd InaccessibleDirectories=/var/lib/yum InaccessibleDirectories=/var/spool [Install] WantedBy=multi-user.target
Strange. This seems to work for me just fine (with perl substituted by echo) (with /sys and /proc read-only or read-write).
"PermissionsStartOnly=yes" should pretty clear make "ExecStartPre" immutable against the readonly namespaces, chroots and other restrictions because it's intention is to prepare things not possible with the restricitions of the main service process maybe you need folders and files below /var/lib/mailgraph/ (look at the chown -R) but the mainpoint is that all the "ReadOnlyDirectories" and "ReadWriteDirectories" should not affect PID1 itself try that and no service won't start with F21 i had that over a very long time for httpd in production the httpd binary is identical, so the breakage is in systemd InaccessibleDirectories=/proc InaccessibleDirectories=/sys the point is that "ExecStartPre" has no permission for chown "/var/lib/mailgraph/" because a race-condition i guess - "ReadOnlyDirectories=/var" should not become active for "/var/lib/mailgraph/" since there is "ReadWriteDirectories=/var/lib/mailgraph" ____________________________________________________ systemd starting with Fedora becomes more and more issues like hanging shutdowns in case of sftp chrootet users with libnss-mysql where kill the system-user session says "/usr/bin/kill: No such file or directory" and i wonder what it needs to issue a kill command itself from outside the process which get the SIGTERM already from "kill"?! https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c109 > The script I run to shutdown my system kills > off all the user manager tasks impossible to work on the sftp-server here because in that context systemd is *buggy like hell* and tries to span /usr/bin/kill while the sftp-sessions is using openssh's sftp-native-chroot and so there is no /usr/bin WHY do systemd need to spawn kill as rection of a SIGKILL to the PID of "/usr/lib/systemd/systemd --user" [root@sftp:~]$ kill 29657 [root@sftp:~]$ cat messages Oct 22 16:51:48 sftp systemd: Failed at step CHDIR spawning /usr/bin/kill: No such file or directory Oct 22 16:51:48 sftp systemd: systemd-exit.service: main process exited, code=exited, status=200/CHDIR Oct 22 16:51:48 sftp systemd: Failed to start Exit the Session. Oct 22 16:51:48 sftp systemd: Dependency failed for Exit the Session. Oct 22 16:51:48 sftp systemd: Oct 22 16:51:48 sftp systemd: Unit systemd-exit.service entered failed state.
additional strange logs on my F21 testserver giving a sign that there is something with cgroups/namespaces *serious* broken [root@testserver:~]$ cat messages | grep CGROUP Jan 21 05:15:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 21 07:30:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 21 13:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 21 16:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 21 21:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 21 22:30:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 21 23:30:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or director
This is probably somehow related to how / is mounted (shared, private, etc). I need to wrap my head around all the modes and changes in that area between F20 and F21.
I can confirm Harald's report at DigitalOcean F21 x86_64. It happens on root login, but *not* every time.
Just to clarify, I'm referring to messages from comment 8 like: Sij 23 23:01:01 gedora systemd[1790]: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory So far I haven't been able to find a pattern to see when the error will happen and when it will not.
Zbigniew Jędrzejewski-Szmek, any chance this is fixed in systemd 216-17? I upgraded to build available on koji and haven't had the "Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory" in last 10 logins or so.
no, maybe not that often but it still happens while that's only some noise compared with the other namespace issues of this bugreport leading to kill tons of systemd-units running from F18-F20 perfectly fine and the nost terrible problem is https://bugzilla.redhat.com/show_bug.cgi?id=1184016#c7 becaus ei don't want to introduce a service before spamassassin to make sure permissions are right just because ExecStartPre is broken now well, i use ExecStartPre on a lot of other places too and don't trust systemd on F21 currently at all [root@testserver:~]$ rpm -q systemd systemd-216-17.fc21.x86_64 [root@testserver:~]$ cat yum.log | grep systemd Jan 21 03:55:42 Updated: systemd-libs-216-16.fc21.x86_64 Jan 21 03:55:45 Updated: systemd-216-16.fc21.x86_64 Jan 21 03:55:46 Updated: systemd-compat-libs-216-16.fc21.x86_64 Jan 22 19:55:54 Updated: systemd-libs-216-17.fc21.x86_64 Jan 22 19:56:01 Updated: systemd-216-17.fc21.x86_64 Jan 22 19:56:02 Updated: systemd-compat-libs-216-17.fc21.x86_64 [root@testserver:~]$ cat messages | grep "Failed at step CGROUP spawning" Jan 25 00:30:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 25 04:30:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 25 10:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 25 11:30:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 25 13:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 25 16:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 25 18:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 26 05:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 26 06:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 26 07:30:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory Jan 26 09:00:01 testserver systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory
Harald, you are right. I see them now as well.
that's all so horrible broken in F21 while it's a bug in SpamAssassin to need locking the bayes-db with disabled autolearning why in the world does "ReadWriteDirectories=/var/lib/spamass-milter/.spamassassin" while have /var/lib read-only as in all releases before? in that case /proc and /sys are untouched which as read-only where the reason for failing - given that random problems and ExecStartPre (https://bugzilla.redhat.com/show_bug.cgi?id=1184016#c5) no longer works as expected Fedora 21 is just unuseable for people crazy enough started using systemd features _____________________________________________________________________ ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/spamassassin ReadWriteDirectories=/var/lib/spamass-milter/.spamassassin InaccessibleDirectories=-/var/lib/spamass-milter/training Jan 27 02:52:57 testserver.rhsoft.net spamd[2794]: bayes: locker: safe_lock: cannot create tmp lockfile /var/lib/spamass-milter/.spamassassin/bayes.lock.testserver.rhsoft.net.2794 for /var/lib/spamass-milter/.spamassassin/bayes.lock: Read-only file system Jan 27 02:52:58 testserver.rhsoft.net spamd[2794]: bayes: locker: safe_lock: cannot create tmp lockfile /var/lib/spamass-milter/.spamassassin/bayes.lock.testserver.rhsoft.net.2794 for /var/lib/spamass-milter/.spamassassin/bayes.lock: Read-only file system Jan 27 02:52:58 testserver.rhsoft.net spamd[2794]: bayes: cannot write to /var/lib/spamass-milter/.spamassassin/bayes_journal, bayes db update ignored: Read-only file system
and BTW that mysqld now works with ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/mysql and creates it's socket-file (https://bugzilla.redhat.com/show_bug.cgi?id=1184016#c4) but for other services make a prent directory ReadOnlyDirectories and one or more subfolders below ReadWriteDirectories resulting in a random behvior makes things only worser
Harald, Zbigniew, I just installed systemd 218-3 for fc22 to see if "systemd: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory" persists.
what is *really* wired is that a combination of "ReadOnlyDirectories" for a parent-folder and then open just a subdirectory with "ReadWriteDirectories" works unpredicatable for some services - postfix as example is happy CAN IT BE that this is borked for services in scripting languages since it affects mailgraph and spamassassin (both written in perl) while at least mariadb and postfix have no probkem (native binaries) ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/postfix [root@testserver:~]$ ls /var/lib/postfix/ insgesamt 28K -rw------- 1 postfix postfix 1,0K 2015-02-09 16:23 prng_exch -rw------- 1 postfix postfix 8,0K 2015-02-09 16:03 smtpd_scache.db -rw------- 1 postfix postfix 12K 2015-02-09 16:03 smtp_scache.db -rw------- 1 postfix postfix 33 2015-02-09 21:59 master.lock
ping - is there any news as said it's obviously a *major regression* that for services at least written in a scripting language having "ReadOnlyDirectories" for a parent folder "ReadWriteDirectories" for subfolders no longer works i would *really* like to upgrade my workstations to F21 for broader tests before consider upgrade production machines but not in a state where services running without any issues from F18-F20 breaking left and right as well i don't want step back to listen every subfolder as "ReadOnlyDirectories" just because i can't relieable make broad restricitons opened where it is really needed
Harald, as much as I dislike this bug, I have to stand on the side of Fedora project here. Fedora is free software; i.e. there is no contract between you and Red Hat (or Fedora Project or any other organization) that obliges anyone to fix bugs you report. So, if you want this fixed, you will either have to: 1) Contribute the patches yourself and convince the maintainer to accept them. 2) Wait for the maintainer to fix them.
> Fedora is free software; i.e. there is no contract > between you and Red Hat did i say that? where? we are talking about the *init system* and *security options* and not something like "player X don't paly my file Y" and in context "Contribute the patches yourself" the only thing i have to say is "did i ask for become the init system more and more complex so that early bugs got mostly fixed from F15 to F19 but with F21 and F22 the systemd feels more and more out of control by the developers because the quick feature bloat?"
I can agree with your view on the importance of systemd. But I do not agree that importance itself implies you can force anyone to fix the bug or steer Fedora Project in a particular direction.
what is your problem? no i can't force anybody to anything - so what - tell me something new but what i can, what i am allowed to and what i do is to point out as often i like it and find it important the major impact of a bug and given that i spent thousands of hours in the past years to test early updates get out of my sight instead try to explain me i am not allowed to state my well deserved option as often i like to do or DO YOU have a contract with somebody which brings you in the position demanding rfom me to shut up? do you think bugs go away if people just ignore F21 until the last day of support and just shut up?
i try now to make some reproducer services on a different F21 VMware-guest the first one is really easy and besides that with "PermissionsStartOnly=true" the "ExecStartPre" should not be affected by namespace restricitons we see here also the issue that "/var/lib/test/subfolder" is explicitly configured as "ReadWriteDirectories" ___________________________________________________________________ Feb 23 16:50:58 rawhide touch: /usr/bin/touch: „/var/lib/test/subfolder/test.txt“ kann nicht berührt werden: Das Dateisystem ist nur lesbar Feb 23 16:50:58 rawhide systemd: test.service: control process exited, code=exited status=1 ___________________________________________________________________ [root@rawhide ~]# cat /etc/systemd/system/test.service [Unit] Description=Test-Service [Service] Type=oneshot User=nobody Group=nobody PermissionsStartOnly=true ExecStartPre=/usr/bin/touch /var/lib/test/subfolder/test.txt ExecStart=/usr/bin/true ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib/test ReadWriteDirectories=/var/lib/test/subfolder [Install] WantedBy=multi-user.target
exactly the same behavior if we try to touch "/var/lib/test/subfolder/test.txt" with "ExecStart" and as you can see below the directories are owned by "nobody" ____________________________________________________________ [root@rawhide ~]# LANG=C [root@rawhide ~]# stat /var/lib/test/ File: '/var/lib/test/' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 811h/2065d Inode: 130889 Links: 3 Access: (0755/drwxr-xr-x) Uid: ( 99/ nobody) Gid: ( 99/ nobody) Access: 2015-02-23 16:41:32.523299826 +0100 Modify: 2015-02-23 16:41:38.617223191 +0100 Change: 2015-02-23 16:42:02.687920622 +0100 Birth: - [root@rawhide ~]# stat /var/lib/test/subfolder/ File: '/var/lib/test/subfolder/' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 811h/2065d Inode: 130912 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 99/ nobody) Gid: ( 99/ nobody) Access: 2015-02-23 16:41:38.617223191 +0100 Modify: 2015-02-23 16:41:38.617223191 +0100 Change: 2015-02-23 16:42:02.655921025 +0100 Birth: - ____________________________________________________________ [root@rawhide ~]# systemctl daemon-reload [root@rawhide ~]# cat /etc/systemd/system/test.service [Unit] Description=Test-Service [Service] Type=oneshot User=nobody Group=nobody #PermissionsStartOnly=true #ExecStartPre=/usr/bin/touch /var/lib/test/subfolder/test.txt ExecStart=/usr/bin/touch /var/lib/test/subfolder/test.txt ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib/test ReadWriteDirectories=/var/lib/test/subfolder [Install] WantedBy=multi-user.target _______________________________________________________________ [root@rawhide ~]# systemctl start test.service Job for test.service failed. See "systemctl status test.service" and "journalctl -xe" for details.
PLEASE not that https://bugzilla.redhat.com/show_bug.cgi?id=1184016#c18 is *really* alarming because we have here completly unpredictable behavior that a "ReadWriteDirectories" in some caes works as override and in some not in case of postfix it works - well, postfix is "Type=forking" and the other cases are "Type=simple" or "Type=oneshot" and maybe *there* is some difference and the bug burried also please keep in mind the usecase of "PermissionsStartOnly=true" to ensure permissions and ownership before "ExecStartPre" - one practical is restart of SpamAssassin running as a restricted user, only need read-permissions and after "sa-update" depending on umask the permissions may not be correct hence we use the construct below because "sa-update" issues a "systemctl restart spamassassin" after the nightly updates and so "ExecStartPre" is the only correct place to fix wrong permissions of random parent folders a own service only doing chmod and ordered before spamassassin won't help in that case and only get effective in case of booting the machine __________________________________________________ [Service] Environment="TMPDIR=/tmp" PermissionsStartOnly=true ExecStartPre=/usr/bin/find /var/lib/spamassassin/ -type d -exec /bin/chmod 0755 "{}" \; ExecStartPre=/usr/bin/find /var/lib/spamassassin/ -type f -exec /bin/chmod 0644 "{}" \; ExecStart=/usr/bin/spamd -c -H --max-children=25 --min-children=10 --min-spare=5 --max-spare=15 --port=10028 ExecReload=/usr/bin/kill -HUP $MAINPID Environment="LANG=en_GB.UTF-8" User=sa-milt Group=sa-milt Nice=15 StandardOutput=null StandardError=null SyslogFacility=mail Restart=always RestartSec=1 PrivateTmp=true NoNewPrivileges=yes CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib ReadOnlyDirectories=/var/lib/spamass-milter/.spamassassin InaccessibleDirectories=-/var/lib/spamass-milter/training
To add some more info / summary: * 216-14.fc21 is good. * 218-*.fc22 is good. * 216-15.fc21 onwards are broken up to and including 216.20; details in bug 1185277 commment 30.
s/216.20/216-20.fc21/ in previous comment.
HOW do you come to the conclusion "216-14.fc21 is good"? you refer to bugreport "Failed at step CGROUP spawning /usr/lib/systemd/systemd" and that is a *completly different issue* hence i opened a own bugreport for that! namesapces are broken too with 216-14.fc21 and this bugreport is about "systemd-216 breaks namespaces" which is a major problem, the "Failed at step CGROUP spawning" is not that kind of problem _________________________________________________________________ [root@rawhide ~]# systemctl start test.service Job for test.service failed. See "systemctl status test.service" and "journalctl -xe" for details. [root@rawhide ~]# cat messages Feb 24 14:45:35 rawhide systemd: Starting Test-Service... Feb 24 14:45:35 rawhide touch: /usr/bin/touch: „/var/lib/test/subfolder/test.txt“ kann nicht berührt werden: Das Dateisystem ist nur lesbar Feb 24 14:45:35 rawhide systemd: test.service: main process exited, code=exited, status=1/FAILURE Feb 24 14:45:35 rawhide systemd: Failed to start Test-Service. Feb 24 14:45:35 rawhide systemd: Unit test.service entered failed state. Feb 24 14:45:35 rawhide systemd: test.service failed. [root@rawhide ~]# cat /etc/systemd/system/test.service [Unit] Description=Test-Service [Service] Type=oneshot User=nobody Group=nobody #PermissionsStartOnly=true #ExecStartPre=/usr/bin/touch /var/lib/test/subfolder/test.txt ExecStart=/usr/bin/touch /var/lib/test/subfolder/test.txt ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib/test ReadWriteDirectories=/var/lib/test/subfolder [Install] WantedBy=multi-user.target [root@rawhide ~]# rpm -qa | grep systemd systemd-libs-216-14.fc21.x86_64 systemd-216-14.fc21.x86_64
in fact even systemd-215 has the broken namespace issues Feb 24 14:53:56 Installed: systemd-libs-215-19.fc21.x86_64 Feb 24 14:53:58 Installed: systemd-215-19.fc21.x86_64 Feb 24 14:53:59 Installed: initscripts-9.55-2.fc21.x86_64 Feb 24 14:54:28 rawhide touch: /usr/bin/touch: „/var/lib/test/subfolder/test.txt“ kann nicht berührt werden: Das Dateisystem ist nur lesbar Feb 24 14:54:28 rawhide systemd: test.service: main process exited, code=exited, status=1/FAILURE
in fact systemd-213-4.fc21 was the last proper working version see below (and please ignore the hostname 'rawhide') * upgraded and downgraded several systemd versions from koji * dracut -f before reboot __________________________________________________________ [root@rawhide ~]# systemctl start test [root@rawhide ~]# cat messages Feb 24 15:01:51 rawhide systemd: Starting Test-Service... Feb 24 15:01:51 rawhide systemd: Started Test-Service. [root@rawhide ~]# rpm -qa | grep systemd systemd-libs-213-4.fc21.x86_64 systemd-213-4.fc21.x86_64 __________________________________________________________ [root@rawhide ~]# systemctl start test Job for test.service failed. See 'systemctl status test.service' and 'journalctl -xn' for details. [root@rawhide ~]# cat messages Feb 24 15:06:20 rawhide systemd: Starting Test-Service... Feb 24 15:06:20 rawhide touch: /usr/bin/touch: „/var/lib/test/subfolder/test.txt“ kann nicht berührt werden: Das Dateisystem ist nur lesbar Feb 24 15:06:20 rawhide systemd: test.service: main process exited, code=exited, status=1/FAILURE Feb 24 15:06:20 rawhide systemd: Failed to start Test-Service. Feb 24 15:06:20 rawhide systemd: Unit test.service entered failed state. [root@rawhide ~]# rpm -qa | grep systemd systemd-libs-214-1.fc21.x86_64 systemd-214-1.fc21.x86_64
well any version after systemd-213 has broken namespaces, yet updated my "rawhide" VM to Fedora 22 and the same - that's scary Feb 25 12:31:16 rawhide systemd: Starting Test-Service... Feb 25 12:31:16 rawhide touch: /usr/bin/touch: „/var/lib/test/subfolder/test.txt“ kann nicht berührt werden: Das Dateisystem ist nur lesbar Feb 25 12:31:16 rawhide systemd: test.service: control process exited, code=exited status=1 Feb 25 12:31:16 rawhide systemd: Failed to start Test-Service. Feb 25 12:31:16 rawhide systemd: Unit test.service entered failed state. Feb 25 12:31:16 rawhide systemd: test.service failed. [root@rawhide ~]# rpm -q systemd systemd-219-4.fc22.x86_64
Fixed upstream in: http://cgit.freedesktop.org/systemd/systemd/commit/?id=a0827e2b123010c46cfe4f03eebba57d92f9efc4 (and the parent commit)
sounds good - a scratch / koji build for F21 somewehre available for testing and confirmation?
F21 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=9246782
looks good - many thanks! this patch is needed for any systemd-build starting form systemd-214 and i will now re-enable all my commented stuff preventing services from start - hopefully we'll see a regular build with that fix, after that i am ready to upgrade to F21 ____________________________________________________ [root@testserver:~]$ systemctl start test.service [root@testserver:~]$ cat messages Mar 17 12:51:52 testserver systemd: Starting Test-Service... Mar 17 12:51:52 testserver systemd: Started Test-Service. [root@testserver:~]$ systemctl status test.service ● test.service - Test-Service Loaded: loaded (/etc/systemd/system/test.service; disabled) Active: inactive (dead) Mär 17 12:51:52 testserver.rhsoft.net systemd[1]: Starting Test-Service... Mär 17 12:51:52 testserver.rhsoft.net systemd[1]: Started Test-Service. ____________________________________________________ [root@testserver:~]$ cat /etc/systemd/system/test.service [Unit] Description=Test-Service [Service] Type=oneshot User=nobody Group=nobody PermissionsStartOnly=true ExecStartPre=/usr/bin/touch /var/lib/test/subfolder/test.txt ExecStart=/usr/bin/touch /var/lib/test/subfolder/test.txt ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib/test ReadWriteDirectories=/var/lib/test/subfolder [Install] WantedBy=multi-user.target
*ping*
systemd-216-23.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/systemd-216-23.fc21
Sorry for the delay. If you could check that this works, thanks.
i confirmed that already at https://bugzilla.redhat.com/show_bug.cgi?id=1184016#c36 and in the meantime upgraded 4 phyiscal machines to F21 after that showstopper was gone
Package systemd-216-24.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-216-24.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-4991/systemd-216-24.fc21 then log in and leave karma (feedback).
systemd-216-24.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.