3 ms·
The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to
by darren0 12y ago
The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.
- cbsmith 12y agoYou may be shocked to discover that socket activation is actually a pretty old idea, and can even be found on non-Linux platforms. systemd embraces it in a pretty big way, but I can't see a problem getting the app containers to work with one of the other socket activation models.
- darren0 12y agoAnd you may be surprised that I ran socket activation well over 15 years ago, so yes I'm well aware of the approach. The comment is more around the fact that in CoreOS's post they seems to harp on the security of a daemon process running as root that is responsible for spawning containers. What I'm saying is that with socket activation you will essentially have that again. Rocket can only work around it today because they have systemd as PID 1 running as root doing the socket activation.
- cbsmith 12y agoWith capabilities there is no need to have privileges beyond port binding and (possibly) userid assignment, no?
- philips 12y agoSocket activation isn't mandated and completely optional. If an application detects it didn't get its sockets it can certainly just start listening instead if it wishes.
- lew21 12y agoSocket activation does not need systemd in any way. You can launch any socket-activated daemon with https://github.com/LEW21/sdlaunch https://github.com/LEW21/sdlaunch - without any dependence on systemd.