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