If systemd refuses to start a service, and gives you a message like this:
Sep 25 17:22:11 mus systemd[1234]: Failed at step NAMESPACE spawning /usr/bin/whatever: Operation not permitted
… then you might have a symlink as your /var/tmp. Make it a real directory, or mount -o bind /tmp onto it. Then systemd can work. (In /etc/fstab, add a line, “/tmp /var/tmp ext3 rbind defaults,rbind 0 3”, where the final 3 is a number higher than your /tmp and /var mount at. I fully expect this to confuse SuSE’s upgrader later, but I can deal with that then.)
This only happens if something uses the
PrivateTmp=true
option in the service file.
SuSE’s exim does this. Others do it for CUPS or httpd.
Once again, systemd comes along and screws up a working system, and provides no feedback about what or why or how. This time searching the Internet wasn’t even useful. I’m so glad I found this bug.
The author (in a post I can not now find) says, “I see no reason to support /var/tmp as a symlink.” Lucky you! I do! What is the reason not to, and is it worth breaking Linux machines that have run for years this way?
Why, you ask, do you want a symlink for /var/tmp?
I don’t want to create a second /tmp partition. I use a separate partition for /tmp, so I can set nodev,noexec,nosuid on it. I’ve had security problems in the past from things executing a payload on /tmp – never again. It’s saved me more than once now.
I want /var/tmp to get that same protection, so it’s a symlink. Symlinks are standard Unix stuff, they’re well understood and work for simple things like this.
So, not only did you break a validly configured system because you’re a bunch of thoughtless, inexperienced jerks, you gave the world’s most useless error message in doing so!
I really want to like systemd. I think it’s trying to do good things. But the people around it, and the complete lack of availability of information it gives you are making that very, very hard. OpenBSD is looking better and better.