Systemd to the rescue(blog.achernya.com)
blog.achernya.com
Systemd to the rescue
http://blog.achernya.com/2014/10/systemd-to-rescue.html
8 comments
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
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.
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.
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.
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?
Four words that strike fear into my heart.
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.
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.
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?
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
Since Ubuntu decided to migrate in the future to systemd [1] you may consider it as a good investment
[1] http://www.markshuttleworth.com/archives/1316
[1] http://www.markshuttleworth.com/archives/1316
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.
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.
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.