On Fri, Jul 15, 2016 at 12:34 PM, Lennart Poettering
On Fri, 15.07.16 08:55, Nico Kadel-Garcia (nkadel(a)gmail.com) wrote:
> On Tue, Jul 12, 2016 at 6:33 AM, Lennart Poettering
> <mzerqung(a)0pointer.de> wrote:
> > On Sat, 09.07.16 21:20, Nico Kadel-Garcia (nkadel(a)gmail.com) 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".
> I'm glad you've commented on the thread. I admit that I was personally
> surprised to find that such a feature had been activated without
> Would it be reasonable or feasible to activate a "WARNING" level for
> UserKillProcess, similar to that used by SELinux? For an admin
> considering this feature, it could be invaluable to generate a day or
> week of logs about which processes *wouild* have been killed. I'm
> particularly thinking of some hand-run backup tools used by former
> colleagues, tools that used all manner of MySQL, Postgresql, rsync,
> dump, tar, and scattered backup tools run manually as opportunities
We can meet in the middle and make this LOG_NOTICE. That's not the
usual LOG_INFO, but also not the higher LOG_WARNING.
Just to verify: I assume you mean that the killing of these processes
would normally emit a "LOG_NOTICE". message. This makes me happier
because it produces *some* kind of log. It's pretty scary to just kill
user processes with no long whatsoever: this is a positive step.
Also to be clear: What about having an alternative "WARNING" setting
for UserKillProcess, one that would generate a log message but not
actually kill processes? That would help developers and admins to run
test systems for some reasonable time, such as a week or so, to audit
for processes that people leave dangling and for which the rocesses
need modification for compatibily with UserKillProcess.
It could also be invaluable for admins faced with software, like
"tux", for which the upstream authors seem unwilling to provide
compatibility with UserKillProcess, but which an admin may
nevertheless want to collect a daily or weekly report of dangling
sessions. It's been pesky to write the necessary cron jobs to generate
such reports. I'd be delighted to have these dangling processes
listed, without actually killing them automatically.