4 ms·

It sounds like systemd journal is a good thing, especially for early boot debugging. That said, I don't get the proposal to remove the standard logger. Sure, th

by coolj 13y ago

It sounds like systemd journal is a good thing, especially for early boot debugging. That said, I don't get the proposal to remove the standard logger. Sure, the logs are duplicated...but having important data stored redundantly seems like a good thing. Plus, you still keep the "everything's a file" philosophy, so you can continue to access the log file in situations where accessing a binary is unfeasible or impossible. The example of a box where /usr is hosed and you only have access to in-memory programs like the shell, is maybe not the best example. Perhaps a more practical one is the need to monitor / alert on certain log entries in a legacy or upstream system that expects to open and watch a file. As all distros I know of include a log file rotation facility that deletes old system logs after some set period, having duplicated data in the journal and in traditional system log on disk seems like it would be a problem only in special cases. Cost-to-benefit, it seems to me there should still be a traditional syslog provider included by default.

ciupicri 13y ago
> The example of a box where /usr is hosed Separated /usr is not recommended anymore (deprecated) and Fedora at least doesn't support this setup.
- coolj 13y ago
  Good point, but not my example.[1] I found it a bit weak tbh. I think a more common and compelling case is where you need to treat the system log as a file input to some existing tool / system. Sure, you can install a traditional logger if you need it in such a case, but what do you gain by not including it? A little bit of disk space? I wonder if there's an unstated motive behind the proposal to promote a more pervasive use of systemd. I mean, being honest, admins aren't going to go to the journal unless they need something the traditional log file doesn't provide (which would be rarely if rsyslog and ilk are pulling everything they can out of journal anyway). Nobody is going to switch to journalctl | fgrep OMGERROR unless they have to (well, they won't have to, but admins are lazy, and if that's the default way, then they will use it rather than installing a new package). Just look how long it took (is taking) for admins to move to ip vs ifconfig/route/etc... [1] http://article.gmane.org/gmane.linux.redhat.fedora.devel/182278 http://article.gmane.org/gmane.linux.redhat.fedora.devel/182...
  - ciupicri 13y ago
    By the way, journalctl already has some built-in filtering, e.g. journalctl PRIORITY=3 _SYSTEMD_UNIT=xxx.service
zb 13y ago
I would wager that 99% of users would fall into one of two categories: 1) The journal is completely adequate for their needs; or 2) No default configuration could ever be adequate for their needs, since they need to configure rsyslog to ship logs off the box. I'm curious as to what sort of cost-benefit analysis would lead you to conclude that everybody in group (1) should be forced to install rsyslog as well so that the perhaps 1% of people who "need to monitor / alert on certain log entries in a legacy or upstream system that expects to open and watch a file" can be spared the horror of having to type "yum install rsyslog".
- coolj 13y ago
  OK, fair enough. Going with your figure (which I think is pretty low), what is the benefit to 99% of users from breaking tools for %1 of users? As far as I can tell it just a bit of additional storage space. Do 99% of users actually benefit from that extra storage?

by coolj 13y ago

ciupicri 13y ago

> The example of a box where /usr is hosed Separated /usr is not recommended anymore (deprecated) and Fedora at least doesn't support this setup.

coolj 13y ago
Good point, but not my example.[1] I found it a bit weak tbh. I think a more common and compelling case is where you need to treat the system log as a file input to some existing tool / system. Sure, you can install a traditional logger if you need it in such a case, but what do you gain by not including it? A little bit of disk space? I wonder if there's an unstated motive behind the proposal to promote a more pervasive use of systemd. I mean, being honest, admins aren't going to go to the journal unless they need something the traditional log file doesn't provide (which would be rarely if rsyslog and ilk are pulling everything they can out of journal anyway). Nobody is going to switch to journalctl | fgrep OMGERROR unless they have to (well, they won't have to, but admins are lazy, and if that's the default way, then they will use it rather than installing a new package). Just look how long it took (is taking) for admins to move to ip vs ifconfig/route/etc... [1] http://article.gmane.org/gmane.linux.redhat.fedora.devel/182278 http://article.gmane.org/gmane.linux.redhat.fedora.devel/182...
- ciupicri 13y ago
  By the way, journalctl already has some built-in filtering, e.g. journalctl PRIORITY=3 _SYSTEMD_UNIT=xxx.service

zb 13y ago

I would wager that 99% of users would fall into one of two categories: 1) The journal is completely adequate for their needs; or 2) No default configuration could ever be adequate for their needs, since they need to configure rsyslog to ship logs off the box. I'm curious as to what sort of cost-benefit analysis would lead you to conclude that everybody in group (1) should be forced to install rsyslog as well so that the perhaps 1% of people who "need to monitor / alert on certain log entries in a legacy or upstream system that expects to open and watch a file" can be spared the horror of having to type "yum install rsyslog".

coolj 13y ago
OK, fair enough. Going with your figure (which I think is pretty low), what is the benefit to 99% of users from breaking tools for %1 of users? As far as I can tell it just a bit of additional storage space. Do 99% of users actually benefit from that extra storage?