[OE-core] [PATCH] systemd: Instruct the journal to always be volatile

[Otavio Salvador]

On Thu, Mar 12, 2015 at 5:04 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Thu, 2015-03-12 at 04:18 -0300, Otavio Salvador wrote:
>> On Thu, Mar 12, 2015 at 12:09 AM, Khem Raj <raj.khem at gmail.com> wrote:
>> >
>> >> On Mar 11, 2015, at 2:28 PM, Randy Witt <randy.e.witt at linux.intel.com> wrote:
>> >>
>> >> When the storage mode for the journal is "auto" if /var/log/journal
>> >> exists then the journal will flush to /var/log/journal assuming that
>> >> /var/log/journal is persistent.
>> >>
>> >> However /var/log -> /var/volatile/log in poky, so even though
>> >> /var/log/journal exists, it is still volatile.
>> >>
>> >> Since this can cause ordering issues due to /var/volatile needing to be mounted before the journal actually writes to it, just specify that the journal
>> >> should always be volatile and never try to write to "persistent"
>> >> storage. The journal will exist in /run/log/journal only.
>> >>
>> >> This also disables the "After" of the journal on var-volatile.mount
>> >> since the ordering is no longer necessary when the journal is only
>> >> stored in /run/log/journal.
>> >>
>> >> [Yocto #7388]
>> >
>> >
>> > This is not right. What if I want persistent logs.? the options is just gone. Both cases should work. /var/volatile should only be used
>> > when doing ro-rfs its not FHS specified anyway. Lets not go with this patch.
>>
>> Agreed.
>
> This isn't quite so simple as "agreed". Are we saying that we want to
> rework volatiles handling after feature freeze?
>
> My view on this is that yes, we do need to do something about it, but
> right now during stabilisation is not the right time. Particularly when
> the patches proposed aren't even tested with sysvinit.
>
> So I'm interested in patches which make things work better without
> making fundamental changes now. We can look at changing volatiles with a
> properly thought out plan in the next development cycle.
>
> Making the systemd configuration match the rest of the default system
> setup would seem to be sensible. We should make it possible for others
> to override that if their setup isn't volatile.

I am saying we should then test the patch (from Khem) and see if it is
valid for merge. Khem being quite active contributor I am sure will be
willing to help to fix any issue for merging (and regression, if any).
I think having the volatile support working is very important and as
we are not releasing tomorrow ...

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750