"Serge E. Hallyn" <serge@xxxxxxxxxx> writes: > Quoting Rui Xiang (rui.xiang@xxxxxxxxxx): >> On 2013/8/8 9:37, Gao feng wrote: >> > On 08/07/2013 03:55 PM, Eric W. Biederman wrote: >> >> >> >> Since this still has not been addressed. I am going to repeat Andrews >> >> objection again. >> >> >> >> Isn't there a better way to get iptables information out than to use >> >> syslog. I did not have time to follow up on that but it did appear that >> >> someone did have a better way to get the information out. >> >> >> >> Essentially the argument against this goes. The kernel logging facility >> >> is really not a particularly good tool to be using for anything other >> >> than kernel debugging information, and there appear to be no substantial >> >> uses for a separate syslog that should not be done in other ways. >> > >> > containerizing syslog is not only for iptables, it also isolates the /dev/kmsg, >> > /proc/kmsg, syslog(2)... user space tools in container may use this interface >> > to read/generate syslog. >> > >> > But I don't know how important/urgent this containerizing syslog work is, >> > Rui Xiang, can you find an important/popular user space tool which uses this >> > interfaces to generate kernel syslog? >> > >> >> There are some other cases. Some warnings (bad mount options for tmpfs, >> bad uid owner for many of them, etc) emerged in the container should >> be exported to the container. Some belong on the host - if they show >> a corrupt superblock which may indicate an attempt by the container >> to crash the kernel. Like these, Kernel will print out warnings when >> userspace in container uses a deprecated something or other, and these >> logs should be invisible and specific for current container. >> >> I can't say this work is terribly compelling and important, but the >> impact may be obvious, IMO. > > Aug 9 21:49:13 sergeh1 kernel: [4644829.672768] init: Failed to spawn network-interface (veth8Ehlvj) post-stop process: unable to change root directory: No such file ricr:aeohgrticr cfe rty444984 n:aetswnw-ta(ht -rrsultheoit: hlrro<4865i:i sntkta(ht ttpe btheoit: hlrrob r6ezt)nrgoadgte644915 c0pt(tyg ti wd a > Aug 9 21:49:13 sergeh1 kernel: X3f d-6:uigitra ora > Aug 9 22:19:54 sergeh1 kernel: 6[642.175 X3f d-6:mutdflsse ihodrddt oe==99 rfl=lccnanrdfutwt-etn"nm=/a/ah/x/lu-ui/m.AExdu"pi=91 om=mut sye"x3name="/devlo0" lg=r"ol pmc r=3an19pfel-nireu-tntgne/rc/cldudmHEqu d97o=otfy=x"ra=d/o/fg""8b:o vhc)nrgibdte646013 veeMzWe oso d<[4715]xr r1eMc egset > Aug That is certainly a mess. Now I don't believe we allow processes in a user namespace to write to the kernels log (certainly we shouldn't be) so part of that is not a problem. What is interleaving messages into syslog? And to be clear my only perspective is that we need to make certain we have this thought out. Eric -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
