On Sat, Nov 2, 2013 at 10:06 PM, Reco <recovery...@gmail.com> wrote: > On Sat, 2 Nov 2013 21:08:29 +0000 > Tom H <tomh0...@gmail.com> wrote: > >> Misrepresenting what systemd is and the reasons for its existence >> doesn't make sense: >> >> http://0pointer.de/blog/projects/systemd.html >> >> OS X and Solaris switched to launchd and smf respectively in 2005 and, >> to borrow an expression from Asterix and Obelix, "the sky didn't fall >> on their heads." Modern nix systems need a more sophisticated >> "/sbin/init" and associated executables and they need (and have needed >> for a long time) something more reliable and maintainable than a bunch >> of dash/bash scripts to bring the system up. > > I've never seen (nor intend to) launchd, but I'm familiar with smf. > And while in Solaris "the sky didn't fall on their heads" indeed, smf > uses ksh scripts for actual launch, check and re-start services like no > tomorrow. And Solaris's svc.startd is actually started by /sbin/init. > Whenever the result is more reliable ('forgetting' to start sshd on a > failed local non-root filesystem mount is one of 'features' of new > Solaris), or maintainable (yes, I always wanted to describe service > dependencies in xml) is subjective, of course. > And smf doesn't provide 'one true API' for service launch nor requires > services to be written in a specific way.
smf uses manifests to manage the ksh scripts, which are far more simple that the pre-smf rc scripts; often just a "case,start/stop/..." mini-script. So the entire management and supervision of the scripts is done through the manifests, which are new to smf. The fact that these manifests are in xml sucks. This is where Scott and Lennart have improved on both launchd and smf (by not using xml) and on smf (by combining the control of the scripts and the scripts themselves with "exec" or "script,end script" in an upstart config file and with "ExecStart=..." in a service file. Furthermore, the fact that Solaris uses "/sbin/init" doesn't mean that it's using that of sysvinit. On Ubuntu, upstart uses its very own "/sbin/init". >> Linux is playing catch-up >> in this field and I'm glad that upstart and systemd are dragging it >> out of the dark ages, even if it's kicking and screaming irrationally. > > Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if > using good ol' sysvinit. So, Lennart fixed what wasn't broken in the > first place. How can you say that sysvinit isn't broken? Did Scott and Lennart both think "sysvinit is perfect but I'm nonetheless going to develop upstart/systemd; my employer won't mind my wasting my time on such a project my distro in a more constructive way"? Both upstart and systemd were developed in order to improve on sysvinit. >From a user perspective: with sysvinit, you can't be sure when you "stop" a daemon that it actually stops. >From a developer (and to a certain extent user/admin) perspective: the following is taken from [1]. <begin> I think it's painfully obvious if you compare an init script to an upstart or systemd configuration file for a simple daemon like, say, my lbcd package. For those who don't agree, please try the exercise of writing systemd and upstart configuration files for some typical daemon package and look at the number of lines of code in both and the behavior in edge cases (daemon already running, daemon running but with no PID file because something else deleted it, daemon part of a dependency chain that shouldn't fire until the daemon is actually listening to the network, correct exit status for various failure conditions, stopping the daemon when there is a user process with the same name as the daemon also running, and the other cases Policy says one must handle). Now compare the length of time it took you to make an init script correctly handle all those cases versus how long it took to write the upstart or systemd configuration. (Note that I have found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while working on Debian, so even if you start from that file, which is only applicable to a relatively narrow range of circumstances, you can still fail edge cases.) </end> [1] http://lists.debian.org/debian-devel/2013/10/msg01099.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=sw_tj6uqq-dnaxlc3bf5wwnoj3bg1d0_+4r-ax4jha...@mail.gmail.com
