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)
>> 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
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
but they did not mention full path to the socket.
"(the socket is not present)"