[the_mitsuhiko]

> less and bunch of files were working much better for me

Just because it works for you does not mean it works for everybody else. The mess of log files below /var/log has been a problem for a long time. The format is not descriptive enough, there timestamps are second resolution only, no timezone information, and yet the times are in local timezone.

Please don't hold on /var/log/messages just because it has been like that for ages. That should not be the justification for it existing.

> I've had a huge pain rewriting couple dozens of init.d scripts with custom logic to service files.

That's funny, because my experience has been that writing init.d scripts is painful and even package maintainers sometimes get it wrong.

[Karunamon]

>The mess of log files below /var/log has been a problem for a long time.

How so? It follows the *NIX "everything is a file" philosophy, so they can easily be processed by other utilities that everybody already knows.

>The format is not descriptive enough

You mean the standard filepath? /var/log/(daemon name).

You mean the actual textual format of a syslog message? Timestamp, daemon, facility.severity, message. If your messages are useless, isn't that a function of what's creating them, rather than what's capturing them? What additional data do you want that you're not seeing?

>no timezone information, and yet the times are in local timezone

What other timezone should they be in? Personally I think it's easier to look at the system clock (actually, I usually don't even have to do that, since I have a clock in the corner of my screen session) and make a mental note what timezone you're in rather than add two bytes to every message.

>Please don't hold on /var/log/messages just because it has been like that for ages. That should not be the justification for it existing.

It's the thing that wants to change the way it's always been done that has to justify itself, not the other way around. What does the systemd journal give us that's worth throwing out decades of knowledge and muscle memory?

Configuring syslog isn't exactly a great feat of skill either.. pick your favorite daemon, it still follows the general format of (messages from this thing) (with this characteristic) (go here)

[bitwize]

It's the thing that wants to change the way it's always been done that has to justify itself, not the other way around. What does the systemd journal give us that's worth throwing out decades of knowledge and muscle memory?

That's how modern systems are developed. That's all the justification you need, really. Define the use cases you and your CADT buddies considered as "modern" and everything else as "legacy", then you can say "That worked fine in the 1970s, but modern systems don't work like that anymore."

[naquad]

> Just because it works for you does not mean it works for everybody else. The mess of log files below /var/log has been a problem for a long time. The format is not descriptive enough, there timestamps are second resolution only, no timezone information, and yet the times are in local timezone.

Have you ever tried to actually configure your syslog?

> Please don't hold on /var/log/messages just because it has been like that for ages. That should not be the justification for it existing.

Seriously, did you ever try to configure it?

> That's funny, because my experience has been that writing init.d scripts is painful and even package maintainers sometimes get it wrong.

For simple cases init.d script is mostly overkill, personally I had to write generator for this stuff. Solved 99% of probles in simple cases. But in complex cases where you split configuration (hello /etc/{conf.d,default}/*) or need to make custom actions (no matter which), service files lose. Now you have to write a wrapper that will be actually started by systemd. Who were saying what about redunant entities?

[tenfingers]

systemd is somewhat better than upstart on some fronts, and equally bad or worse in others.

For instance, I like upstart init files much better that systemd "services". Their ini-like syntax is very limiting if you need embedded scripts. I'm looking at you, PreExec. Wrapping everything through "sh -c" looks hideous, and it's not an advantage.

upstart init files with logrotate's syntax are way more readable. The "script" blocks avoid the "sh -c" escaping madness for you.

both upstart and systemd don't "get" live system debugging. I complained loudly both on debian and on the systemd mailing list, but people don't seem to grasp the concept:

If my system doesn't boot (no console), I'm f$#@. The daemon is waiting for some event to occur, but I have no clue which one.

With standard init, there are very few commands to respawn. The system is much more robust. getty on a local tty is part of them, and as such I never had a system where I couldn't debug startup issues.

With upstart/system, if I have an issue with udev (very common between updates), I do not get anything, even though the system is ready enough to start one.

What I need is a sysrq like binding for "force-start a getty now please". I need to be able to query init and ask "what even target are you /going/ to, which events are requisites and still not met? There are the obvious things you need to debug dependency-based systems.

But you don't have them.

No. But instead you can kill the running system, and reboot with "verbose boot". Because a scrolling terminal with 20 lines/sec helps apparently (hint: it doesn't - the system will still hang). So after that you can reboot once more, with init=/bin/sh and boot yourself.

The same issues go for shutdown.

I have nothing against systemd. Dependency-based boot is great. But both init systems seem to miss that a critical piece like init needs to be small, robust and debuggable.

I'm running systemd on unstable. I've lost count of the times that the system didn't boot properly because of an udev change that incurs in a dependency loop. This should never happen. Shutdown doesn't work since two months if you have a cryptsetup system, again because of a stupid unmet dependency.

Plus, again, systemd ini-file scripts are fugly. You need external scripts just to run Pre/Postexec.

Many of the design decisions behind Lennarh are, IMHO, regrettable. This goes way beyond systemd in general.

Fortunately systemd seems to be going forward somewhat, thanks to debian mostly, and like I said before, dependency-based boot is nice.