systemd has some nifty comparatively recent functionality that lets you do some quite similar things, with higher isolation. I mention it because I find it real

systemd has some nifty comparatively recent functionality that lets you do some quite similar things, with higher isolation. I mention it because I find it really cool, some of the possibilities are quite eye-opening, and many, perhaps most, services would benefit from switching from static to dynamic user IDs plus StateDirectory et al. to manage /var directories. https://0pointer.net/blog/dynamic-users-with-systemd.html https://0pointer.net/blog/dynamic-users-with-systemd.html The specific example use case that matches here: > By combining dynamic user IDs with socket activation you may easily implement a system where each incoming connection is served by a process instance running as a different, fresh, newly allocated UID within its own sandbox. Here's an example waldo.socket: [Socket] ListenStream=2048 Accept=yes > With a matching waldo@.service: [Service] ExecStart=-/usr/bin/myservicebinary DynamicUser=yes > With the two unit files above, systemd will listen on TCP/IP port 2048, and for each incoming connection invoke a fresh instance of waldo@.service, each time utilizing a different, new, dynamically allocated UID, neatly isolated from any other instance. By allocating a new user ID for every invocation, you definitely limit the number of instances you can run—systemd only has a pool of 4336 dynamic user IDs (61184–65519) to allocate from, beyond which point I presume it’d refuse to accept any more connections. But it’s cool stuff, anyway. (You could also just go for socket activation without a dynamic user, but I was thinking of this from the dynamic user perspective because that’s the more novel thing; socket activation has been around for much longer.)