On Mon, Aug 25, 2014 at 7:57 PM, Steven Haigh <[log in to unmask]> wrote: > On 26/08/2014 9:36 AM, Vladimir Mosgalin wrote: >> - 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. For debugging: systemctl status network.service systemctl status NetworkManager.service For failures: I haven't any networking problems and the guys testing RHEL7 at my $dayjob haven't reported any such problems. >> - 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. You can/should use a snippet such as /etc/systemd/system/<daemon>.service.d/*.conf which consist of, for example, EnvironmentFile=-/etc/sysconfig/daemon >> - 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. systemctl status <daemon>.service ?! > 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. journald forwards its logs to rsyslog by default so logwatch and co shouldn't have any problems.