On Mon, 4 Nov 2013 15:43:36 +0000 Tom H <tomh0...@gmail.com> wrote: > 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.
Solaris 11.1, more or less default non-X install. There're 17 scripts exceeding 10k in /lib/svc/method. Smallest script is 248 bytes, largest one is 41627 bytes. They must've put entire Shakespeare poetry in Solaris 9 in init scripts if they reduced them in Solaris 10. RHEL 5.9, non-X install. There're 2 scripts exceeding 10k in /etc/rc.d/init.d. Smallest script is 128 bytes, largest one is 14793 bytes. Debian 7.1, X install. There're 2 scripts exceeding 10k in /etc/init.d. Smallest script is 117 bytes, largest one is 18483 bytes. > 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 I agree with you. > 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. Ok, good. But there's noticeable difference between ksh scripts smf uses and forking and execing binaries like system does. That difference is troubleshooting. > 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". Smf respects /etc/inittab, systemd does not. If it takes to write /sbin/init replacement for such compatibility - I'm fine with that. If certain init does not respect this configuration file - that's bad. > > 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? Let me think… Because it's works most of the time? You know, it allows booting, starting and stopping services. It may be broken, but it's good enough. > 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"? Yet their corresponding employers could view such 'time wasting' as an excellent opportunity to play a little vendor lock-in game. > Both upstart and > systemd were developed in order to improve on sysvinit. Their developers surely say so. I would be surprised if they'd say otherwise. Still, they must be correct in the case of RHEL sysvinit. That thing is a real mess imo. > >From a user perspective: with sysvinit, you can't be sure when you > "stop" a daemon that it actually stops. True. But tell me, can systemd kill processes in the 'uninterruptable sleep' state (aka D-state)? Or, quickly unmount NFS filesystem mounted with 'hard' option even if NFS server is down? Can upstart do these wonders? > >From a developer (and to a certain extent user/admin) perspective: the > following is taken from [1]. > > <begin> <skipped rant about 'writing a script is hard'> > </end> > > [1] http://lists.debian.org/debian-devel/2013/10/msg01099.html If that's the only problem, they could adopt, say, [2] without breaking anything else. [2] http://thomas.goirand.fr/blog/?p=147 Reco -- 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/20131104205633.4488e176412ab96b3e823...@gmail.com
