[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 23.09.2014 um 19:41 schrieb Jóhann B. Guðmundsson:
> On 09/23/2014 04:15 PM, Przemek Klosowski wrote:
>> On 09/22/2014 12:53 PM, DJ Delorie wrote:
>>>> For the journal you always keep all log history in it's original
>>>> state
>>> On low-bandwidth systems, like laptops or diskless nodes, it's a
>>> performance hit to generate the log entry in the first place.  It's
>>> really important to be able to configure the system to *generate* a
>>> minimal amount of communications.  Being able to filter the results
>>> later is a separate issue.
>> That's a very good point: many systems do not fall into the 'infinite disk' desktop-like category. Case in point:
>> embedded systems like Beaglebone, Rasberry Pi, etc.: their entire disk is 2GB of flash storage. Logging is still
>> useful for them but needs to be very flexible and minimal.
> 
> There seems to be some common misconception that systemd is not being in use by the embedded crowd or does not
> adhere to their needs but the embedded system you are mentioning there are already using systemd and journal along
> with few more and their journal ( journald.conf ) settings usually boil down to something like this and serves
> their need...
> 
> [Journal]
> Storage=none
> SystemMaxUse=10M
> MaxLevelStore=info
> MaxLevelSyslog=info

that may all be true

but the above configuration leads to supress possible interesting
messages from daemons which not flood the log and is only needed
because some components are more verbose than needed for normal
operations instead get only verbose in a debug-level

in normal operations you only need two events logged in case of
a cronjob a) started and b) finished which does crond anyways

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140923/e88d5432/attachment.sig>