On 08/18/2016 07:47 AM, Erik Skultety wrote:
> Now that previous patches tried to refactor the code and split parsing and
> defining logic of logging primitives, there is no reason why we could not keep
> journald's fd within the journald output object the same way as we do for
> regular
Now that previous patches tried to refactor the code and split parsing and
defining logic of logging primitives, there is no reason why we could not keep
journald's fd within the journald output object the same way as we do for
regular file-based outputs. Quite the opposite, by doing that we gain
