5 ms·

This is one of many reasons why I love Debian. Very agnostic, very reasonable approaches to issues like this, and above all, whether or not systemd ends up as t

This is one of many reasons why I love Debian. Very agnostic, very reasonable approaches to issues like this, and above all, whether or not systemd ends up as the default, I can almost guarantee people will still have the option to very easily switch to (or from) it in Debian. That being said, I can definitely second many of the top concerns listed, chief among them: non-greppable logs (binary formatted) and too much complexity/trying to do too much.

jlgreco 13y ago
I had no problems with systemd when I was using Fedora on my laptops (I never had to interact with it at all), though right now I'm using Debian without systemd and have no problems either. I don't really have a dog in this fight; it seems either solution is going to stay out of my hair and do what it needs to. Nevertheless, the concept of binary logs really annoys me and I have yet to see a satisfying explanation of why it should be necessary. The best I've seen is "well windows uses binary logging too" and "the syslog text format sucks", but neither of those satisfies. Windows does plenty of shit that should not be mimicked, and the benefits of text logging are severely dampened on Windows anyway (on account of Windows not being Unix.) Furthermore, the syslog text format sucking is not an argument for not using text logs in general, only an argument for not using the syslog text format specifically. Why can't we have a reasonable non-syslog text format for logs?
- anonyfuss 13y ago
  > Why can't we have a reasonable non-syslog text format for logs? I think the real question is: why is systemd defining a logging format at all?
  - jlgreco 13y ago
    Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....). I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that should be done in such close connection with systemd. A better approach would be to make rsyslog more than just a syslog daemon and build up a new protocol and storage format with it, with the full intention of standardizing it. (the syslog protocol is a pain in the ass, particularly that hard limit on facility numbers... Fix that first, then roll from there. Make rsyslog treat syslog like Vim treats vi: capable of falling back to compat mode, but better by default.)
    - anonyfuss 13y ago
      > Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....). Technically indeed. If you try to forcibly disable journald, it causes causes dependency failures that result in you dropping to an emergency prompt. Of course this doesn't stop Lennart Poettering from using the existence of separate but interdependent daemons as 'proof' that systemd isn't a monolithic ball of mud. > I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that should be done in such close connection with systemd. A better approach would be to make rsyslog more than just a syslog daemon and build up a new protocol and storage format with it, with the full intention of standardizing it. (the syslog protocol is a pain in the ass, particularly that hard limit on facility numbers... Fix that first, then roll from there. Make rsyslog treat syslog like Vim treats vi: capable of falling back to compat mode, but better by default.) Agreed. This is what Apple did with asl(3); it's a modern syslog replacement that happens to still support the syslog protocol and syslog(3) APIs. There's no reason a modern logging daemon can't be portable to other systems, too; it shouldn't be doing anything so crazy as to be impossible to run elsewhere, whereas since systemd is an intentionally non-portable kitchen sink, no other UNIX is going to run with journald.
- thaumaturgy 13y ago
  I have had a problem with it -- or, rather, a problem which it made more difficult. From a comment a few months ago in a systemd thread (https://news.ycombinator.com/item?id=5124589 https://news.ycombinator.com/item?id=5124589): > "Getting smbd/nmbd to work again was a real adventure. Like other users reported, it would just silently fail when starting it from systemd. No error message when issuing the start command, and only a vague "failed" in status. I ended up having to track down Lennart's blog post on "systemd for administrators" to figure out how in blazes to extract anything useful from that cussed binary log system he invented. My first half-dozen or so attempts to get anything useful out of the log journal got exactly zero results; I finally got lucky on another approach..." I'm really not fond of the idea of having to search logs for information. Being able to page through them is actually super nice. Being able to tail -f them while kicking a process over and over again to see why it's mad at me is also really nice. I think I've heard that some people have come up with tools that will translate the binary log data back to text again, which helps, but that seems a little silly. I'm running Debian (on everything that's not running BSD) now in part because they've been deft so far about handling the transition to systemd. I'm sure Debian will switch to it eventually, but I also trust them to make sure the major issues are all dealt with before they do.

jlgreco 13y ago

I had no problems with systemd when I was using Fedora on my laptops (I never had to interact with it at all), though right now I'm using Debian without systemd and have no problems either. I don't really have a dog in this fight; it seems either solution is going to stay out of my hair and do what it needs to. Nevertheless, the concept of binary logs really annoys me and I have yet to see a satisfying explanation of why it should be necessary. The best I've seen is "well windows uses binary logging too" and "the syslog text format sucks", but neither of those satisfies. Windows does plenty of shit that should not be mimicked, and the benefits of text logging are severely dampened on Windows anyway (on account of Windows not being Unix.) Furthermore, the syslog text format sucking is not an argument for not using text logs in general, only an argument for not using the syslog text format specifically. Why can't we have a reasonable non-syslog text format for logs?

anonyfuss 13y ago
> Why can't we have a reasonable non-syslog text format for logs? I think the real question is: why is systemd defining a logging format at all?
- jlgreco 13y ago
  Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....). I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that should be done in such close connection with systemd. A better approach would be to make rsyslog more than just a syslog daemon and build up a new protocol and storage format with it, with the full intention of standardizing it. (the syslog protocol is a pain in the ass, particularly that hard limit on facility numbers... Fix that first, then roll from there. Make rsyslog treat syslog like Vim treats vi: capable of falling back to compat mode, but better by default.)
  - anonyfuss 13y ago
    > Well, technically I suppose systemd doesn't, journald does (and systemd requires journald, and journald is made and shipped by the same people....). Technically indeed. If you try to forcibly disable journald, it causes causes dependency failures that result in you dropping to an emergency prompt. Of course this doesn't stop Lennart Poettering from using the existence of separate but interdependent daemons as 'proof' that systemd isn't a monolithic ball of mud. > I'm not opposed to a "next-gen syslog", but yeah, that isn't a push that should be done in such close connection with systemd. A better approach would be to make rsyslog more than just a syslog daemon and build up a new protocol and storage format with it, with the full intention of standardizing it. (the syslog protocol is a pain in the ass, particularly that hard limit on facility numbers... Fix that first, then roll from there. Make rsyslog treat syslog like Vim treats vi: capable of falling back to compat mode, but better by default.) Agreed. This is what Apple did with asl(3); it's a modern syslog replacement that happens to still support the syslog protocol and syslog(3) APIs. There's no reason a modern logging daemon can't be portable to other systems, too; it shouldn't be doing anything so crazy as to be impossible to run elsewhere, whereas since systemd is an intentionally non-portable kitchen sink, no other UNIX is going to run with journald.
thaumaturgy 13y ago
I have had a problem with it -- or, rather, a problem which it made more difficult. From a comment a few months ago in a systemd thread (https://news.ycombinator.com/item?id=5124589 https://news.ycombinator.com/item?id=5124589): > "Getting smbd/nmbd to work again was a real adventure. Like other users reported, it would just silently fail when starting it from systemd. No error message when issuing the start command, and only a vague "failed" in status. I ended up having to track down Lennart's blog post on "systemd for administrators" to figure out how in blazes to extract anything useful from that cussed binary log system he invented. My first half-dozen or so attempts to get anything useful out of the log journal got exactly zero results; I finally got lucky on another approach..." I'm really not fond of the idea of having to search logs for information. Being able to page through them is actually super nice. Being able to tail -f them while kicking a process over and over again to see why it's mad at me is also really nice. I think I've heard that some people have come up with tools that will translate the binary log data back to text again, which helps, but that seems a little silly. I'm running Debian (on everything that's not running BSD) now in part because they've been deft so far about handling the transition to systemd. I'm sure Debian will switch to it eventually, but I also trust them to make sure the major issues are all dealt with before they do.