On 26/08/2014 9:36 AM, Vladimir Mosgalin wrote:
> Hi Ken Teh!
> 
>  On 2014.08.25 at 12:58:21 -0500, Ken Teh wrote next:
> 
>> I read the following article on systemd
>>
>> http://ifwnewsletters.newsletters.infoworld.com/t/9625863/474699771/826094/14/
>>
>> The comments suggested one could still revert to sysvinit.  Is this just wishful thinking on my part?
> 
> Yes. As an exercise, why don't you revert EL6's upstart to sysvinit?
> Note that enabling/disabling some services on EL6 *requires* you to use
> upstart-specific initctl, you simply won't notice these services if you
> will only look at chkconfig.
> 
> systemd offers many benefits for system administrators, like:

No, no it doesn't.

> - simple and predictable service files

Like my case of networking randomly failing to start. No debugging or
errors logged, and no way of predicting a failure.

> - ability to wrap a random application into service with just a few lines of config

Yes and no. When you really start using systemd, you learn quickly how
to create service files - because you end up writing a lot of them
because basic options are missing. If your app doesn't utilise a config
file, then you can bet you'll be copying across the default systemd
service file and modifying it to suit your needs. There is no other way.

> - no more extra-complicated init scripts using various hacks and magic
> for non-C applications (if you ever tried to wrap some random python or
> java application into service, you'll know what I'm talking about right
> away)

By complicated you mean working? I start several python daemons on boot
with initscripts - and it is very simple - almost trivial. Compare to
the guesswork of trying to find out why a service failed to start.

> - automatic restart of services

This is not always desirable.

> - thanks to these features (service created with few lines of code,
> automatic restart, some others) - no more need for runit, daemontools or
> supervisord , you can have all the benefits of these systems while having
> only one flat init system (systemd) for both system and your services
> - reliable pid tracking, which even follows the forks - that's something
> not current init system or others like runit are able to do. No more
> hassle with complex pgrep's for applications that didn't leave pidfile
> behind (again, applications that rename or fork themselves and non-C
> applications can be extremely annoying here). But systemd has reliable
> way of knowing all the pids that each service has created without any
> hacks at all - thanks to cgroups support.

None of which really works out of the box without you writing your own
service file. We have used /var/run for PID files for decades - saying
it isn't reliable is .... ignorance?

> - ... many more, like various niceties for supporting lightweight
> containers with blazing fast startup, where systemd cares about
> organizing namespaces and initializing network by itself (not sure these
> features are in EL7's systemd, though)

None of these really matter in enterprise land. When the servers RAID
card takes longer to boot than even the initscripts to run, the benefits
are shown for what they are - trivial.

> really, for everyone who spent many hours wrapping developers'
> applications into services or had to bother with various hacks and
> scripts "to let this stupid application daemonize more easily" like
> forever, runit, supervisord or misses various features of solaris smf in
> linux, systemd is a real bliss.

Oh god no. Systemd replaces many things that should not be replaced.
Plans are afoot to have systemd replace ntpd and the idea to replace the
kernel consoles with userspace systemd foo. Lets also ignore the binary
log formats which kills long time monitoring tools (logwatch etc) and
systemd really is a solution hunting for a problem.

Systemd would have a much better time if it kept its core goal small and
focussed. The mess that it has evolved into has included blowing out its
scope to just about everything on your system. This is the wrong way to
do things. There is no excuse for violating the basic principles of
system design and administration for 'wooo it boots faster'.

-- 
Steven Haigh

Email: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299