On Sat, 09.07.16 21:20, Nico Kadel-Garcia (nkadel@xxxxxxxxx) wrote: > > In either case it will be up to FESCO to decide and set guidelines on > > implementation and for us grognards to either deal with the change or > > go find an OS we can be happier in. > > It looks to me like the critical change to even consider activating > this dangerous policy is to *log* the killing of userland processed. > Date, euid, guid, and pid are a minimum: the name of the process would > be even better, and the contents of the process invocation command > line would be even more useful. > > Can systemd even gracefully poll for that information at the time of > killing these processes? Or would systemd developers feel a need to > re-invent "ps" from scratch to report this? I figure it would be OK to add code to systemd that logs about all processes we kill with SIGKILL and all processes we kill after a "scope" unit is "abandoned". (Regarding the terms used above: In systemd "scope" units are a concept how groups of processes not started by PID 1 are maintained, very similar to a "service" unit, the only difference being that "services" are forked off by PID 1 itself, while "scopes" are started by other code. Login sessions are maintained in "scopes" as it is not systemd that starts their processes but getty/gdm/... And "abandoning" a "scope" is what happens when the process that created the "scope" goes away before the "scope" itself goes away. This is what happens to the login "scopes" as soon as gdm/getty/... consider the session having ended.) I think logging about all processes we send signals to (i.e. SIGTERM) would be too much, as this pretty typically happens all the time, for example when a service is terminated. Logging about SIGKILL and abandoned scope process is different however, as in that case the processes conceptually are "left over", as the clean shutdown logic (which is SIGTERM, or the scope's owner shutting it down propery) apparently didn't work. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
