Quoting Andrew Morton (akpm@xxxxxxxxxxxxxxxxxxxx): > On Mon, 19 Nov 2012 01:51:09 -0800 ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote: > > > Are there any kernel print statements besides networking stack printks > > that we want to move to show up in a new "kernel log" namespace? > > That's a good question, and afaict it remains unanswered. There are some other (not *terribly* compelling) cases. For instance selinux hooks, if you say mount an fs without xattr support or with unsupported options, will printk a warning. Things like stat.c and capabilities and syslog print out warnings when userspace uses a deprecated somethingorother - old stat syscall or sys_syslog without CAP_SYSLOG. That should go to the container. Filesystems may give warnings (bad mount options for tmpfs, bad uid owner for many of them, etc) which belong in the container. Obviously some belong on the host - if they show a corrupt superblock which may indicate an attempt by the container to crash the kernel. > As so often happens, this patchset's changelogs forgot to describe the > reason for the existence of this patchset. Via a bit of lwn reading Not as a separate justification admittedly, but the description was meant to explain it: right now /dev/kmsg and sys_syslog are not safe and useful in a container; syslog messages from host and containers can be confusingly intermixed; and helpful printks are not seen in the container. > and my awesome telepathic skills, I divine that something in networking > is using syslog for kernel->userspace communications. > > wtf? Well, syslog is the kernel->userspace channel of last resort. > Wouldn't it be better to just stop doing that, and to implement a > respectable and reliable kernel->userspace messaging scheme? Convenience functions on top of netlink? > And leave syslog alone - it's a crude low-level thing for random > unexpected things which operators might want to know about. That sentence is a result of not calling a container admin an operator. I can't argue it because I'm not sure whether to agree with that classification. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
