[SSSD] [PATCHES] Enable sending DEBUG logs to journald

Stephen Gallagher sgallagh at redhat.com
Wed May 7 20:27:41 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNqlz0ACgkQeiVVYja6o6O1iACcDu/R+6+iPEfHlWimyMBVflNx
eX8AnAkuAdyCXdFronR6765ez7iwFYTG
=XnI8
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list