4 ms·
I had no idea systemd can do that. It sounds kinda exploitable. Is the ability to do that even a good idea?
by krick 3y ago
I had no idea systemd can do that. It sounds kinda exploitable. Is the ability to do that even a good idea?
- cyberax 3y agoSystemd is awesome, but at this point it has so much functionality, that it's hard to know what it can do. It needs to _seriously_ improve discoverability and documentation.
- WhyNotHugo 3y agoFWIW, there are other (portable) services which implement an fd store too.
- singron 3y agoFd stores are an awesome way to do this too. We used to start up a new version of the process and then they would have to find each other and pass the fds. It's pretty complicated and it's a weird model for the supervisor.
- conradev 3y agoThe functionality is key for socket-activated daemons which is a Big Idea behind systemd: it can launch daemons on-demand instead of at boot, allowing for faster boot times
- pengaru 3y ago> The functionality is key for socket-activated daemons which is a Big Idea behind systemd https://en.wikipedia.org/wiki/Launchd#Socket_activation_protocol https://en.wikipedia.org/wiki/Launchd#Socket_activation_prot...
- conradev 3y agoI don’t fully understand the relevance of that paragraph, but launchd and systemd both work this way, both for similar reasons I do believe that launchd came first: https://news.ycombinator.com/item?id=2565780 https://news.ycombinator.com/item?id=2565780
- pengaru 3y agoI only linked it because launchd is the source of the "Big Idea", predating systemd by ~5 years. Perhaps I misunderstood your comment in interpreting it to say socket activation's an original systemd concept.
- agrover 3y agohttps://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd came out in 1978, if we're keeping score.
- pengaru 3y agoTrue! But the launchd style of socket activation integrating into the dependency graph of service startup is what's novel and alleviates some significant challenges to concurrent starting of interdependent services...
- kelnos 3y agoThe person who raised it just said socket-activated daemon is "a Big Idea" behind systemd. They didn't say or imply that systemd invented it, just that systemd is based on that pattern.
- moomin 3y agoYes. But the Iron Law of systemd is that you should never mention it unless you’re prepared for a tangential argument about systemd and other init systems.
- conradev 3y agoYes! I should have explicitly spoke to that, because it wasn't the source of the idea I was trying to respond to "Why does systemd have to store file descriptors?" with "That's actually the entire point of its existence"
- fodkodrasz 3y agoIt is not a launchd innovation, its from the late 1970s: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd
- lupusreal 3y agoI don't understand why faster boot times was ever a priority in the first place. I know it's a metric that linux ricers sometimes like to compete on, but normal users just suspend their computers when not in use 99 times in 100.
- bryanlarsen 3y agoLinux use in computers that can suspend is negligible compared to the number of instances of Linux in random gadgets that you expect to work as soon as you turn them on.
- deleted 3y ago[deleted]
- speed_spread 3y agoIts not faster boot that matters but that the system can have many more services configured and pending activation. It makes a much more dynamic OS possible, which matters in a world of mobile computers that dock and connect to new hardware and networks all the time.
- bluGill 3y agoMore than once I've known I have an early meeting and got to my desk just before the clocked turned - but by the time I got into the meeting several minutes had past. I work with people around the world, sometimes you need someone in Germany, India, Australia, and Basil to all meet at the same time - there is no way to pick a good time for everyone, and the closer you get for one person the worse things get for someone else so you end up with barely acceptable times for everyone as the best compromise.
- taneliv 3y agoI was thinking along the same lines---doesn't it allow for "permanent memory leaks"? I mean, if someone has just bugs in their (possibly non-Rust) code, not necessarily trying to exploit anything.