Marko Randjelovic <markoran <at> eunet.rs> writes: > > > > > That's exactly how I feel when I want to create a small daemon using a > > SystemV init script. I feel like building an airplane from scratch while > > I would just use a bike. > Sure, systemd is "bloated". Just like the kernel is bloated, I presume. A kernel which runs on anything from bikes to space planes. (Literally.)
A systemd service file is five lines. Want more features? Add more lines. > Use /etc/init.d/skeleton and you'll see it's very simple. > Want more features in your init script? Like, say, a reliable way to figure out if any parts of your server are still running after it crashed? Or a way to determine that it has started up correctly? Or a reliable log of all of its output in one location? (With a filter that dumps the last 100 lines of debug log to disk _only_ if there's an error right behind them!) Or a way to figure out which dependency prevented your daemon from running (and which seamlessly resumes bootup when you fix the problem)? Or a pre- determined environment without stupid surprises like a LOCALE set to Chinese (or something more insiduous like, say, an ignored signal) when you start something by hand? Or a private /tmp? Or any other of the cool features systemd offers? systemd: For each of these, add a line to your service script. If it's not the default anyway. SysV: Sorry, you're screwed. (Mostly.) SysV init scripts do not even *have* a reliable dependency system. The SysV manager can tell that the thing started and didn't exit nonzero, but that's not always the same thing as "running". > Shell is a programming language. It cannot be less flexible then config > files. *than. Besides, this is not about flexibility. You're free to run a small and simple shell script to start your service if you need to, just like today you're free to hide your not-so-small and no-longer-simple script (see above about reliably detecting whether a service is in fact up) inside a bloated SysV init script. This is about features. Many of the features systemd provides (and which I refuse to live without, having become accustomed to them over the last year or so) are, by basic Unix design, not available to something that is not PID 1. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20131108t130649-...@post.gmane.org
