

Systemd to the rescue - lizdenys
http://blog.achernya.com/2014/10/systemd-to-rescue.html

======
mperham
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.

------
eeZi
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.

------
acabal
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.

------
digi_owl
So he pretty much hit on what Systemd has been built towards, cloud computing.

What rankles people is not journald pr say tho, but its tight coupling with
the rest of the systemd ensemble.

You can't tell systemd to not start journald and just do logging via syslog or
whatever you have been using. You still have to run journald in a pass through
form.

Meaning you can't introduce systemd parts piecemeal, you only get the whole
glob or not at all.

------
pdkl95
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](https://bugs.freedesktop.org/show_bug.cgi?id=64116)

~~~
mmastrac
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.

~~~
pdkl95
I'm not suggesting that systemd and/or journald is responsible for the
corruption of the logs; it could be, but this bug report doesn't really
suggest anything about the original source of the corruption.

The source doesn't matter, because corruption happens. Bugs happen, hardware
fails, attackers try to cover their tracks. The bug I (and the original
reporter in this bug report) are referring to is journald's behavior when
corruption happens: shove the log aside and start from scratch. Even worse,
the attitude that ignoring corruption is "not a bug" is insane.

Yes, fixing a corrupt binary database (even a simple one) is going to be
_very_ hard. What they fail to mention is that the reason they are face with
this difficult problem was their decision to use that kind of format in the
first place. When faced with the realities of their bad design choices,
pretending there isn't a problem is not the correct answer. The correct way to
handle that bug report should have been either fixing the bug (make journalctl
able to handle corrupt logs), changing previous bad designs (drop the format
that makes this a problem), or at a bare minimum recognize that this is a
serious problem for some people and leaving the report open if it cannot be
fixed right now.

Given that this kind of external corruption has a very good chance of being
the _very reason_ you have to search the logs, how a logger acts in that kind
of situation is of key importance.

------
bsmith
As a n00b to init systems, who has recently started using Upstart with Ubuntu
in production...should I switch to Systemd? What are the pros/cons over
Upstart? Is there anything inherently flawed about the robustness of Upstart?

~~~
mperham
There's nothing wrong with Upstart and it's pretty easy to use. I've got a
little wiki page with some examples here:

[https://github.com/mperham/inspeqtor/wiki/Upstart](https://github.com/mperham/inspeqtor/wiki/Upstart)

------
mzs
Along the same lines couldn't per user log files be used for apached, googling
reveals a number of recipes for that, or alternatively hack suexec in a same
way to that end?

------
davecheney
Four words that strike fear into my heart.

