On Wed, Jan 09, 2013 at 12:31:05PM -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/09/2013 11:55 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Jan 09, 2013 at 05:44:02PM +0100, Zbigniew Jędrzejewski-Szmek > > wrote: > >> On Wed, Jan 09, 2013 at 11:00:36AM -0500, Daniel J Walsh wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>> > >>> One of my goals with setroubleshoot analysys is to get it integrated > >>> into the journald system. > >>> > >>> In Fedora I am adding > >>> > >>> systemd.journal.send(siginfo.format_text()) > >>> > >>> Which will put the setroubleshoot info into the journal, but what I > >>> really need is to add a key for the process id that created the journal > >>> entry. > >>> > >>> We had talked about this a while ago with the goal of allowing > >>> something like > >>> > >>> systemctl httpd status .... SELinux is blocking httpd read access on > >>> /var/www/index.html setroubleshoot ... run restorecon > >>> /var/www/index.html > >>> > >>> The only way for systemd to know the setroubleshoot analysys is for > >>> httpd is to include the pid when setroubleshoot writes the journal. > >> Hi, > >> > >> the way that finding messages pertaining to a certain service works > >> currently is encoded in src/share/logs-show.c, function > >> show_journal_by_unit: - journald adds _SYSTEMD_UNIT=... when it can to > >> messages generated by the services themselves - systemd (PID 1) writes > >> messages about services with UNIT=... and journalds tags them with > >> _PID=1 - COREDUMP writes messages with COREDUMP_UNIT=... > >> > >> I think it would be realitively to extend show_journal_by_unit() to > >> check > > ^relatively easy > >> for messages with _SYSTEMD_UNIT=setroubleshootd.service (or whatever) and > >> UNIT=... Would this work for you? This would require setroubleshootd to Probably SYSTEMD_UNIT would be better here.
> >> find out the unit name on its own. Actually, this might be for the > >> better, since by the time that journald gets the message, the PID might > >> be long gone, and setroubleshootd has more knowledge. > > A second part would be support for multiline messages. This is another > > story. > > > > Zbyszek > > > > Well I got two problems, then. How does setroubleshoot figure out which unit > file is associated with a pid? (From python). We could either expose the C functions (sd_pid_get_session is already public, and it would be nice to add a Python interface, shortened_cgroup_path could be easily made public, cg_pid_get_unit is not public yet either), or create a rewrite in Python and put it in the systemd-python package, or even do nothing and let each user rewrite it. I think option two would be easiest, but maybe option one is worth pursuing. Option two would be a bit more work, but might help keep things synchronized in the future. Yeah, it seems best, since the combined work required to rewrite sd_pid_get_session, shortened_cgroup_path, and cg_pid_get_unit is pretty big. > And if the pid is not > associated with a unit file but with a User or something else (systemd > itself), what should I do? I think just duplicate journald logic: add SYSTEMD_SESSION, SYSTEMD_OWNER_UID if possible, or nothing. Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
