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.