On (09/05/14 08:48), Stephen Gallagher wrote:
On Fri 09 May 2014 04:12:42 AM EDT, Lukas Slebodnik wrote:
> On (07/05/14 16:27), Stephen Gallagher wrote:
>> On 05/06/2014 09:41 AM, Lukas Slebodnik wrote:
>>> Could we try to fix this issue?
>>>
>>> I had a related problem with logging in container. The daemon
>>> journald isn't running in container and sd_journal_sendv
>>> ignores this situation.
>>>
>>> k = sendmsg(fd, &mh, MSG_NOSIGNAL); if (k >= 0) return 0;
>>>
>>> /* Fail silently if the journal is not available */ if (errno
>>> == ENOENT) return 0; ^^^^^^^^^^^^^^^^^^^ The debug message was
>>> not logged in systemd and sd_journal_sendv did not fail and
>>> therefore we could not fall back to the standard output.
>>>
>>> I don't want to argue with systemd developers about this
>>> behaviour, but I would like to see debug messages in
>>> containers. My current workaround is to log into files, but it
>>> has a lot of disadvantages for me.
>>
>> Failing silently REALLY doesn't seem like correct behavior here.
>> I did some digging and the reasoning behind it is that otherwise,
>> it breaks a lot of software when running in mock/chroot.
> containers are almost like a chroot and it breaks logging in
> containers. The problem is solved in mock, new problem is
> introduced in containers It is double edged sword. The biggest
> problem is that it is not documented (man sd_journal_send)
>
https://bugzilla.redhat.com/show_bug.cgi?id=1096067
>
>>
>> From talking to journald devs, the recommended approach for us
>> should be to link against libsystemd-daemon and call sd_booted()
>> during process start. This will return 0 or 1, depending on
>> whether systemd was used to boot the system. If it returns 0, we
>> should defer to the traditional logging path rather than using
>> the journal.
> calling function sd_booted is not solution. It can fix one problem,
> but it will introduce another problem.
>
> With containers, you can mount bind directory from a host machine
> to a container. This would solve problem mith missing log messages,
> but your solution will break this workaround. The functions from
> library libsystemd-journal.so would be able to send messages to the
> journald, but systemd is not booted (sd_booted return negative
> value) and we will send debug messages to the stderr
>
> We could test if socket "/var/run/dbus/system_bus_socket" exists
> but it is relying on undocumented location of socket.
Wouldn't it make more sense to bind in /run/systemd/journal/socket?
copy&paste problem :-) (yet another problem in IT)
That's supposedly a well-known location and that's really all
that
should be needed to dump the logs out to the parent journal, I think.
It is not
guaranted that this socket will not be moved to another place.
systemd has rapid development.
BTW. manual page was updated
http://cgit.freedesktop.org/systemd/systemd/commit/?id=bdf9fc1a
but they did not mention full path to the socket.
"(the socket is not present)"
LS