Systemd to the rescue

I like systemd from the perspective that it seems to be pushing forward features like no other project. Say what you will about the Unix ethos, it's 2014 and most people are still cobbling together ugly init.d scripts and rotating our own logs instead of deferring that work to the OS.

Having done a LOT of research on init systems over the last few months, systemd was the most controversial but also the nicest to use. I look forward to its introduction in Ubuntu.

Congrats on getting to a situation that works for you, but I would gently suggest that having to custom-patch suexec of all things might not be the best way to approach a long-term solution. I don't know how that aspect of the solution reflects on systemd though.

I built a wifi repeater using a Raspberry Pi and two USB wifi adapters. The USB setup was not particularily stable and the devices would randomly reset.

Thanks you systemd, all I had to was to create two systemd units, for hostapd and the NetworkManager connnection setup, and declare a hard dependency on the USB wifi adapters. This was possible thanks to the udev integration - you can simply declare a dependency on a device just like you would do for a service. systemd would then cleanly stop the particular unit if the device disappeared, and start it once it re-appeared.

Of course, I could have done something similar using just udev and a service supervisor, but systemd made it as simple as adding a few lines to my unit description files. It was a rather unusual use case, and I was amazed at how easy it was to implement it.

journald? The log where corruption bugs are considered[1] NOTABUG? That on its own is enough reason to stay away. Pretending that log parsers don't exist makes this a nasty case of "not invented here".

Use that risky mess if you want. I'm sure it will work great in most cases. Just remember that some of us value stability and a proven track-record more than fast searching. Especially when log parsers give us the fast searching too.

If you could use journald as a stand-alone log parser that slurped up and indexed the syslog, it might be a very useful tool. Forcing s reversal of sane design when it is not necessary is either is either a sign of inexperience or an "embrace and extend" existing methods.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=64116

I think you've misrepresented the bug. "when reading we try to make the best of it" -- that sounds like they've done their best to work around files that are corrupted externally, not that journald is actually corrupting logs itself.