On Sun, 18 Mar 2012 18:23:37 -0400 "Walter Dnes" <waltd...@waltdnes.org> wrote:
> On Sun, Mar 18, 2012 at 03:15:02PM +0200, Alan McKinnon wrote > > > Here's what I want: > > > > When the machine starts, I want services X, Y and Z to run. The > > software figures out what order they must start in and how the deps > > work. Clean, neat, easy. > > systemd is like Captain Picard of STTNG (Start Trek The Next > Generation) always saying "make it so". *HOW DO YOU "MAKE IT SO"? > That intelligence has to be somewhere. So what alternative do you > propose? A bash or ash script is more guaranteed to run than a > binary. Shoving all that "intelligence" into the service itself, > means that the service has to start up in order to determine whether > it's safe for the service to start up. What's wrong with this > picture? The intelligence goes in the init system's config file for that service of course. I know I didn't clearly say so, but that's where it goes. The information isn't complicated, you need some BEFORE and AFTER type settings and various other bits and pieces (pid files etc). For services that don't behave nicely when stopped and started in "regular ways", supply start/stop/restart/reload functions in the same file that override the defaults. In principle it mirrors exactly how portage works with ebuilds. > And if systemd is so great, here's my supersystemd > > #!/bin/bash > ... > ... > /etc/init.d/net.lo start > /etc/init.d/net.eth0 start > /etc/init.d/net.sshd start > etc, etc, etc No no, you misunderstand me. I'm not saying necessarily that systemd is great. I'm saying that sysvinit sucks big-time and we've needed something better for 15 years. Systemd's design seems to fit that bill nicely (whether it does it in practice remains to be seen) -- Alan McKinnnon alan.mckin...@gmail.com
