On 07/12/16 14:59, Tejun Heo wrote: > On Mon, Jul 11, 2016 at 07:47:44PM +0000, Topi Miettinen wrote: >> It's really critical to be able to associate a task in the logs to >> cgroups which were valid that time. Or can we infer somehow what cgroups > > When is "that time"? Without logging all operations, this is > meaningless. > >> a task was taking part, long time after task exit? Perhaps task cgroup >> membership changes and changes in available cgroups should be logged too? >> >> Some kind of cgroup IDs could be logged instead of long paths. Then >> these IDs should be reliably resolvable to paths offline somehow. > > I don't think that's doable. That pretty much requires the kernel to > remember paths of all past cgroups. That's a show stopper for audit approach for getting helpful information for configuration. I'll try something different, probably cgroupstats. -Topi > >> How usual migrations between cgroups are? Why would a task ever move >> from (say) systemd/system.slice/smartd.service to anywhere else? > > In most cases, they won't move once set up initially but that's not > the point of audit subsystem. Logging this once one exit isn't gonna > help anything for auditing the system. > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
