It's not a matter of the init scripts. It's not that my apps are not compatible with systemd. Systemd is not compatible with my system.
Unless you mean that Linux is not compatible with your system, you're wrong. Now I'm pretty sure you're clueless or at least inexperienced.
Systemd depends on features which I can't give it in my environment. My environment is an unprivileged container. In this environment you CANNOT have use of prctl for security isolation (kinda sucks, yeah), you CANNOT have /dev as a tmpfs, and you CANNOT have access to the control groups at the kind of granularity. Systemd will not work without these features - I've tried.
So you're definitely clueless. You don't understand what you're talking about. You are in an unprivileged container, but you STILL need a privileged manager in this container, and that manager is systemd. That doesn't mean everything else is privileged. Your system just won't work without a privileged equivalent to PID 1.
prctl is not a systemd prerequisite. Nothing prevents you from using /dev as a tmpfs (you can even lock its size) and you won't have access to CG as systemd will take care of them.
Basically, having your prerequisites doesn't prevent you from running a systemd in a OS container or force you to remove systemd features, as that's not what you're asking for. You're asking for an unprivileged container, which doesn't mean at all that the systemd inside the container has to have anything removed.
Now, nothing prevents you from running systemd containers with sth else than systemd, you'll just lose eveything systemd brings to the table in the process.
Were this a sysvinit system I'd just edit the init script to remove the bits I don't need. With systemd I need to recompile a binary and deal with the troubleshooting that results.
This doesn't make sense: you want systemd within a OS container without systemd dependencies. Use sth else, then! No one is stopping you, you can still use your sysvinit + init scripts, you're on your own anyway with your custom needs.
Now, these are based on my usage of CentOS 7 which is already 2 years old on top of the release delays. I'm sure newer versions make the situation better. But at this very moment systemd has made a VERY bad first impression (there's more, but I'm not going to go into that) and left me with no practical solution. All the other things like "binary logging" just make me even more irritated.
You are making a bad impression of yourself actually, what you wrote shows you don't know what you're doing, or what is really asked of you.
I hate to reply to myself, but I realized a technical error or two. You can use /dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.
You still show you don't even understand what you're reading.
Apparently you try to use /dev as tmpfs yourself, which you don't need to do and shouldn't do, as systemd is already managing that for all your services.
And they're not talking about dropping mknod unsupported, but about dropping the CAPABILITY being unsupported. Which makes perfect sense, as in devtmpfs, the kernel is making the nodes in your /dev, which you should not touch. But in a container, the /dev is isolated from the base OS, and you have to be able to make nodes in it one way or another, and this is by using a process that have the CAP_MKNOD capability. That's because everything in your container is unprivileged. Or else you will have an empty /dev, so a container that won't work with a Linux kernel. As I said earlier, you don't understand what was asked of you in a unprivileged container, which is exactly what systemd will provide to you. But you have to understand the link you've given to know that.