Change... to what?

Posted Nov 21, 2011 23:05 UTC (Mon) by anselm (subscriber, #2796)
In reply to: Change... to what? by jmorris42
Parent article: That newfangled Journal thing

Who went away and put you in charge of deciding what is Linux and what isn't? There is no reason why we must stick forever with the arbitrary design decisions of the 1970s and 1980s. Lots of aspects of Linux are worth re-thinking. This does not mean that the first alternative proposal for »whatever« must be accepted by everyone, but also that there are no holy cows. (And that you are free to maintain Holy Cow Linux, with none of the newfangled improvements, for however long you care to do so.)

If somebody (not necessarily Lennart Poettering) comes up with a proposal to improve a notoriously badly-designed part of the system such as the logging infrastructure, then that person should at least be heard out. It may just be that they have something good going. That only Lennart and Kay seem to have the cojones to actually tackle some of these things should really give us pause.

In other words: Change is not necessarily for the better but it is also not necessarily for the worse. Biology has a word for things that never change. They're called »dead«.

to post comments

Change... to what?

Posted Nov 23, 2011 23:16 UTC (Wed) by dlang (guest, #313) [Link] (7 responses)

when you say that syslog is so horribly designed and so limited it makes me think that you haven't used a modern syslog (rsyslog or syslog-ng). Those are both good examples of projects that have added a lot of capabilities to logging, but have done so in ways that are compatible with the existing system while providing the additional power to those who want/need it

this journal proposal sounds like the dozens of logging systems I've seen proposed by junior programmers for their applications. They assume that they know all the needs and so can design the perfect monolithic logging infrastructure.

to paraphrase a common quote

"syslog is the worst logging design ever, except for everything else"

Change... to what?

Posted Nov 25, 2011 4:33 UTC (Fri) by HelloWorld (guest, #56129) [Link] (6 responses)

> when you say that syslog is so horribly designed and so limited it makes me think that you haven't used a modern syslog (rsyslog or syslog-ng). Those are both good examples of projects that have added a lot of capabilities to logging, but have done so in ways that are compatible with the existing system while providing the additional power to those who want/need it
The Journal _is_ compatible with the syslog(3) api. And while it doesn't implement the syslog protocol, it is easily possible to write a gateway tool that implements the protocol and forwards messages to the Journal in order to be stored; in fact this possibility is mentioned in the proposal.
It would be really helpful if people would actually _read_ such proposals before whining about them.

Change... to what?

Posted Nov 25, 2011 5:34 UTC (Fri) by dlang (guest, #313) [Link] (5 responses)

I have read the proposal

It's "compatible" with syslog in that if you are willing to throw out it's advantages of being structured and trusted you can encapsulate syslog data in journal messages.

but if you have done this, what exactly is the advantage of this new tool?

and if you can go the other way and have the journal entries put into nicely formatted structured syslog messages, why do you need the journal to do this again instead of just writing the nicely formatted messages to syslog in the first place?

Especially if you like writing your log entries via a library, there is absolutely nothing preventing you from using a library that writes structured messages to syslog.

Change... to what?

Posted Nov 25, 2011 9:18 UTC (Fri) by anselm (subscriber, #2796) [Link] (3 responses)

Especially if you like writing your log entries via a library, there is absolutely nothing preventing you from using a library that writes structured messages to syslog.

Except that clients will still be able to lie to the syslog service about their identity, etc. Structured messages are one thing that The Journal is about, but Lennart and Kay do address a fair number of other concerns. Some of these might be amenable to changes to rsyslogd, but others are more difficult to treat within that framework while Lennart and Kay do seem to have a handle on them. I think their proposal at least bears thinking about.

Change... to what?

Posted Nov 25, 2011 9:25 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

>> Especially if you like writing your log entries via a library, there is absolutely nothing preventing you from using a library that writes structured messages to syslog.

> Except that clients will still be able to lie to the syslog service about their identity, etc. Structured messages are one thing that The Journal is about, but Lennart and Kay do address a fair number of other concerns. Some of these might be amenable to changes to rsyslogd, but others are more difficult to treat within that framework while Lennart and Kay do seem to have a handle on them. I think their proposal at least bears thinking about.

actually, journald is only able to avoid the application lieing to it for programs that are started by systemd and do all their logging through systemd.

This could be done with normal syslog by creating a unique /dev/log replacement for each application group that's started and then tagging to indicate which one the log arrives on (modern syslog daemons already allow you to have multiple sources and to know which source the log came from)

If anything else generates logs to journald in any way that bypasses the library, that thing could also lie about who it is. good programs won't do this, but good programs won't lie about who they are in the first place (unless they have a good reason to do so, which is very possible)

Change... to what?

Posted Nov 25, 2011 9:58 UTC (Fri) by michich (guest, #17902) [Link] (1 responses)

It does not matter what library you use to talk to journald. It is not possible to lie about who you are. Search for SCM_CREDENTIALS in the proposal. See also SCM_CGROUPS, SCM_COMM in http://0pointer.de/blog/projects/plumbers-wishlist.html

rsyslog now has 'trusted properties'

Posted Dec 1, 2011 3:43 UTC (Thu) by dlang (guest, #313) [Link]

it turns out that rsyslog already used SCM_CREDENTIALS to let you log the pid of the program, it's now added the ability to log some additional values

_UID The userid under which the logging process is being executed.
_GID The group id under which the logging process is being executed.
_PID The PID of the logging process. Note that this PID, if configured, is also put into the syslog tag.
_EXE Path to the binary that is logging
_COMM The name (as visible by top) of the logging process.
_EXE The full command line of the logging process. Note that this string can contain spaces, thus it is always provided in quoted form.

http://blog.gerhards.net/2011/11/trusted-properties-in-rs...

http://www.rsyslog.com/what-are-trusted-properties/

now that didn't take scrapping all existing logging practice to get did it?

Change... to what?

Posted Nov 25, 2011 9:20 UTC (Fri) by michich (guest, #17902) [Link]

Even with the syslog(3) api you still get some of the benefits: addition of the underscore-prefixed fields, indexing by these fields, per-user read access to their own logs.