Am 06.08.2015 um 12:16 schrieb Lennart Poettering:
On Thu, 06.08.15 10:57, Reindl Harald (h.rei...@thelounge.net) wrote:So, you'll get this EEXIST error only if there's already something at the place of the runtime dir that is either:NOBODY but systemd creates that directory it don't exist at all before the service is started the problem is that SOMETIMES at stop is seems not to be removed and so the next start failsWhether it is removed or not should not matter really, the code is completely fine already exists as long as the uid/gid/mode match (as mentioned before).
no, the code is *not* fine"Failed at step RUNTIME_DIRECTORY spawning" for the *ExecStartPost* in nonsense since it is already created *before* ExecStart
Aug 6 12:31:24 rh systemd: Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists
why in the world is soemthing to spawn at that point? the RntimeDirectory is for the whole service
the second problem is that SOMETIMES systemd creates RuntimeDirectory for ExecStart *and* ExecStartPost and if that happens ExecStartPost fails and so the service too which is killed hence while the main process is already running fine you *really* should look at https://bugzilla.redhat.com/show_bug.cgi?id=1226509#c3Any chance you can reduce this to a minimal test case? The unit file has a lot of settings that are almost certainly unrelated to the issue at hand?
surely, the reason do add all the options is that *every single day* randomly mysqld instances are failing which uses exactly that options introduced with Fedora 21 to replace the tempfiles-stuff and as often systemd-related Fedora bugs are open for months
___________________________________________________ [root@rh:~]$ cat /etc/systemd/system/test2.service [Unit] Description=Test Unit [Service] Type=simple User=nobody Group=nobody RuntimeDirectory=test2 RuntimeDirectoryMode=0750 ExecStart=/usr/local/bin/loop.sh ExecStartPost=/usr/bin/true [Install] WantedBy=multi-user.target ___________________________________________________ repeatly call of systemctl stop test2; systemctl start test2; sleep 1; cat messages sooner or later it fails Aug 6 12:31:18 rh systemd: Stopped Test Unit. Aug 6 12:31:18 rh systemd: Starting Test Unit... Aug 6 12:31:18 rh systemd: Started Test Unit. Aug 6 12:31:20 rh systemd: Stopping Test Unit... Aug 6 12:31:20 rh systemd: Stopped Test Unit. Aug 6 12:31:20 rh systemd: Starting Test Unit... Aug 6 12:31:20 rh systemd: Started Test Unit. Aug 6 12:31:21 rh systemd: Stopping Test Unit... Aug 6 12:31:21 rh systemd: Stopped Test Unit. Aug 6 12:31:21 rh systemd: Starting Test Unit... Aug 6 12:31:21 rh systemd: Started Test Unit. Aug 6 12:31:23 rh systemd: Stopping Test Unit... Aug 6 12:31:23 rh systemd: Stopped Test Unit. Aug 6 12:31:23 rh systemd: Starting Test Unit... Aug 6 12:31:23 rh systemd: Started Test Unit. Aug 6 12:31:24 rh systemd: Stopping Test Unit... Aug 6 12:31:24 rh systemd: Stopped Test Unit. Aug 6 12:31:24 rh systemd: Starting Test Unit...Aug 6 12:31:24 rh systemd: Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists Aug 6 12:31:24 rh systemd: test2.service: control process exited, code=exited status=233
Aug 6 12:31:24 rh systemd: Failed to start Test Unit. Aug 6 12:31:24 rh systemd: Unit test2.service entered failed state. Aug 6 12:31:24 rh systemd: test2.service failed.
It would be good if you could verify that file data of the runtime dir when this fails for you. Thanks.I'd still like to see the permission and ownership of the runtime dir when this failed
since the service fails and systemd removes the runtime dir that's impossible but for the cases where it does not fail:
[root@rh:~]$ stat /run/test2/ File: '/run/test2/' Size: 40 Blocks: 0 IO Block: 4096 directory Device: 13h/19d Inode: 234535 Links: 2 Access: (0750/drwxr-x---) Uid: ( 99/ nobody) Gid: ( 99/ nobody) Access: 2015-08-06 12:34:26.772338048 +0200 Modify: 2015-08-06 12:34:26.772338048 +0200 Change: 2015-08-06 12:34:26.772338048 +0200 Birth: - [root@rh:~]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
