On (07/05/14 16:27), Stephen Gallagher wrote:
On 05/06/2014 09:41 AM, Lukas Slebodnik wrote:
> On (24/02/14 08:40), Stephen Gallagher wrote:
>> On 02/24/2014 05:54 AM, Jakub Hrozek wrote:
>>> On Thu, Feb 20, 2014 at 08:47:30AM -0500, Stephen Gallagher
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> On 02/19/2014 05:18 PM, Lukas Slebodnik wrote:
>>>>> On (19/02/14 22:03), Sumit Bose wrote:
>>>>>> On Wed, Feb 19, 2014 at 09:04:48PM +0100, Lukas
>>>>>> Slebodnik wrote:
>>>>>>> On (19/02/14 12:37), Jakub Hrozek wrote:
>>>>>>>> On Wed, Feb 19, 2014 at 12:02:23PM +0100, Jakub
>>>>>>>> Hrozek wrote:
>>>>>>>>>> I realized I made a mistake in the rebasing
>>>>>>>>>> above. I fixed that and then needed to do
another
>>>>>>>>>> manual rebase of these patches atop it. These
>>>>>>>>>> patches apply atop the "[SSSD] DEBUG macro
>>>>>>>>>> refactoring v6" patches.
>>>>>>>>>
>>>>>>>>> These patches work for me, so ACK.
>>>>>>>>
>>>>>>>> Pushed to master.
>>>>>>>
>>>>>>> find_uid-tests failed with these patches on fedora20.
>>>>>>>
http://kojipkgs.fedoraproject.org//work/tasks/8367/6548367/build.log
>>>>>>
>>>>>>
>>>>>>>
>>>>
>>>>>>>
>>
>>>>>>>
Do you have additional patches in this build?
>>>>>>
>>>>>>
/builddir/build/SRPMS/sssd-1.11.90-0.20140219.1816.git22a9323._temp.fc20.src.rpm
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>>>
>>
>>>>>>
The git hash does not look like anything from master.
>>>>>>
>>>>> Yes, I was testing some patches.
>>>>>
>>>>>> I started a koji build
>>>>>>
http://koji.fedoraproject.org/koji/taskinfo?taskID=6549081
>>>>>>
>>>>>>
with current master
>>>>>> (4cde267bec52ae1723a125d19439a5c75b47ebb7) which is
>>>>>> working fine.
>>>>>>
>>>>> I tried one more time with master and koji works fine.
>>>>> Unfortunately, I am able to reproduce it locally in mock
>>>>> :-(
>>>>>
>>>>
>>>>
>>>> I've seen that happen intermittently as well in mock and
>>>> koji. I suspect there may be a bug/race condition in
>>>> sd_uid_get_sessions(), but I can't reproduce it consistently
>>>> (and the DEBUG error doesn't seem to fire...)
>>>>
>>>> A quick look at the code suggests that we're probably missing
>>>> a 'return EOK' after '*result = false', though.
>>>>
>>>> I'll run a couple tests and see if that fixes the issue...
>>>
>>> I found another issue related to journald support..if you
>>> compile sssd with journald support and run it on the foreground
>>> (-i) then the debug messages are still redirected to journal.
>>> That seems strange to me, but also in line with what a comment
>>> in the code says:
>>>
>>> /* If we are not outputting logs to files, we should be
>>> sending them * to journald. * NOTE: on modern systems, this is
>>> where * stdout/stderr will end up
>>>
>>> So I'm not entirely sure about the expected behaviour, but I
>>> would prefer if there was still a way to see the debug messages
>>> directly on the console.
>>>
>>> I hacked up a patch that also adds a third state where if sssd
>>> is running on the foreground even with journald support, then
>>> just fprintf is used. See the attachment.
>>>
>>
>>
>> Sorry, I completely forgot about the *real* foreground case
>> there. I was thinking purely of how SSSD works when launched by
>> systemd. In that case, if it runs in the foreground, the output
>> is trapped.
>>
>> I don't love this particular implementation (it's clearly a
>> hack), but I also can't think of another approach (aside from
>> adding a new command-line flag to enable sending to journal
>> instead of files and leaving the default as stdout/stderr).
>
> 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.
LS