-----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----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
