[ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

[Alex Carver]

Not if it's an all or none proposition.

Example, right now I can set up filters to have rsyslogd take syslog
input and either drop it to a file or, for things that are noisy,
shuttle them off over the network to something that actually has a
reasonable amount of storage (something many of my embedded systems
don't have).  For the documents that I can find, *everything* goes to
the journal with no option to filter and you must choose to have all of
it go to disk and/or duplicate it over the network.  You can't have a
mix.  If I'm wrong about this I want to see the documentation about how
to filter what gets written to the journal and what doesn't.

Note that I'm not talking about journalctl's post-filtering methods.
The data is already down on disk or away elsewhere  by this point.  I'm
talking about decision making prior to committing a write to the log.
Using the normal syslog devices I can tank a noisy daemon without ever
touching the disk.


On 2015-09-10 11:18, Michael Trausch wrote:
> The journal is actually one of the most excellent things, coming from am embedded perspective where the SBC replaces the MCU and dedicated host board. Crashes go straight to the journal if you want them to. It is excellent for both debugging and production, and can hold arbitrary binary key/value data. It effectively replaces my own custom solution for the same thing with a universal interface. 
> 
> Sent from my iPhone
> 
>> On Sep 10, 2015, at 11:10 AM, Alex Carver <agcarver+ale at acarver.net> wrote:
>>
>>> On 2015-09-10 07:51, Derek Atkins wrote:
>>> Jim Kinney <jkinney at jimkinney.us> writes:
>>>
>>>> It's got to be better than having systemd foistered on us by RedHat.
>>>
>>> This just bit me yesterday; updated a system from F21 to F22 which
>>> REMOVED syslogd!!  OOPS.  And I was wondering why I didn't get any
>>> logwatch email!!!  Well, duh, there are no logs anymore!  Stupid systemd
>>> journal.  WTF are they thinking????  How is this "BETTER"?
>>
>> This is not going to be good for embedded systems.  Apparently the
>> journal is a take-it-or-else proposition because the journal consumes
>> the output of all services.  Disabling the journal means cutting off
>> logging for services.  The only things I've been able to find are the
>> storage options and those are awful.  You either have it store to disk
>> and other programs read and parse the journal logs but not in real time
>> (this is not good for a small, flash based device like the Raspberry Pi,
>> that's just harming the flash storage) or you store the logs in memory
>> and have the other programs parse the memory (again not good for limited
>> RAM embedded systems).  The only option left is a setting called "none"
>> which apparently disables the journal entirely but that cuts you off
>> from all the output from services since the journald is still running
>> and sucking up the output but it's just dropping it on the floor.
>>
>> The format of the logs is also different so standard log parsing isn't
>> going to work either unless you have something pull in the journal and
>> rewrite it to standard log format.
>>
>> Third, standard logging programs have no access to the boot logs if you
>> disable the journal.  Those logs are lost unless you log to an external
>> logging daemon over the network.
>>
>> This is all an interpretation of what I read from the journald man page.
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>