On Sat, 2015-01-10 at 10:11 +0100, Dominick Grift wrote: > On Fri, 2015-01-09 at 22:12 -0500, Paul Moore wrote: > > systemd has taken over cron too? I suppose that is a logical extension, > > but still... > > That is were i think davej is wrong. Here is what i think is the > scenario with cron. > > Cron runs jobs on behalf root. Root is generally not logged in all the > time. So every time cron performs a job on behalf of root (hourly etc), > systemd logind creates /run/user/0 and mounts tmpfs on it, when the job > is done, tmpfs is unmounted and /run/user/= removed. > > In that sense cron acts as kind of a login program. > > Where i think davej might be wrong is that this would also happen with > systemd's replacement for cron: timers. > > I suspect that systemd logind does not create 0 user runtime directory > everytime a timer is triggered, as opposed to cron. > > with regard to normal user timers.Those really only work if you enable > lingering on the systemd --user daemon with logind. This means that in > practice the user is always logged in from a systemd logind user runtime > directory point of view (e.g. /run/user/$UID is always there for a user > that has a lingering systemd session daemon instance) > > In practice , i suspect that this means that, although now with cron > were seeing logind mount tmpfs whenever some job of behalf of root is > run if root is not physically loged in (which is often), that this would > not be the case if we got rid of cron and if it would be replaced by > systemd timers > > One might ask the question: why does logind create a root user runtime > directory every time cron runs a job on behalf of root. Is that really > required? > Never the less. On systems with many users login and out regularly you will see this message often. because when a user logs in /run/user/$UID is created and tmpfs is mounted on it. When the user logs out tmpfs is unmounted, and /run/user/$UID is removed ... unless that users' systemd --user instance is lingering. > > > > -- > > paul moore > > www.paul-moore.com > > > > > > > > On January 9, 2015 4:01:29 PM Dominick Grift <dac.override@xxxxxxxxx> wrote: > > > > > On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote: > > > > On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote: > > > > > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote: > > > > > > We already reduced that message to KERN_DEBUG. Is that not sufficient? > > > > > > > > > > That doesn't really help with the flooding of dmesg, so no. > > > > > I should also note that it's not just logging in that creates a new > > > > > session, it also seems to be getting triggered by cron jobs, or > > > > > whatever the systemd replacement is. > > > > > > > > I wonder if this is cron/systemd/whatever creating a new namespace and > > > > mounting a new tmpfs in the namespace? If yes, I wonder if we could > > > limit the > > > > messages to the initial namespace ... ? > > > > > > > > > > It is systemd logind creating sessions (e.g. creating /run/user/$UID and > > > mounting a tmpfs on it) > > > > > > > > > > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
