Probably should not report this as a failure.

For values other than -1, it's probably still indicative of a misconfiguration on the host, but suppressing the error message when the login UID is 0xffffffff (in practice, uid_t is unsigned) sounds reasonable.

agreed. thanks Nalin.

Fixed in docker-1.9

docker-1.9.1-1.el7.x86_64

Nov 24 20:38:21 eparis-submit-queue-registry.osop.rhcloud.com Docker[20861]: {Action=json, ID=18e21090551b6807ad1a0f5073e5b673dd608611befee643789d904ef3516f1d, LoginUID=4294967295, PID=20902}

Nov 24 20:38:21 eparis-submit-queue-registry.osop.rhcloud.com Docker[20861]: {Action=json, LoginUID=4294967295, PID=20902}

Nov 24 20:38:21 eparis-submit-queue-registry.osop.rhcloud.com docker[20861]: time="2015-11-24T20:38:21.051626373Z" level=error msg="Failed to get pwuid struct: user: unknown userid 4294967295"

Getting better.  The error message is gone in docker-1.9.1-3.el7.x86_64

I'm still getting tons and tons of log spam in the steady state using kubernetes.

 Examples:

{Action=json, ID=b243494a4a8941266b45656723b0fe17488fd22d7f88bf1cb1a55c1681497a1b, LoginUID=4294967295, PID=21041}

{Action=json, LoginUID=4294967295, PID=21041}

{Action=version, LoginUID=4294967295, PID=21041}

I have `OPTIONS=--selinux-enabled --log-level=warn` in my /etc/sysconfig/docker

This is the syslog messages on managers of docker.  We have added syslog and audit log.  How often is k8s contacting docker?  Perhaps we need a way to throttle messages.

Those messages seem devoid of useful information. What is it telling me? Also note I specifically requested a docker log level of warn, because docker was too spammy about things...

I'm getting about 75,000 or 10Meg of messages per hour.

removing the level=info I get so much duplicate.

{Action=json, LoginUID=4294967295, PID=10661}
time="2015-11-25T14:21:40.595754961Z" level=info msg="GET /containers/json"

These things should be merged, and let me drop all this 'info', no?

My 2c: Docker should support basically disabling auth{z} logging for kubelet.  Or more generally for any non-human users.

The problem with that then is that an admin could easily get around logging/auditing by setting up a system service that triggers docker to do stuff on their behalf.

I have changed the admin logging patch to follow dockers logging and to log at "info" level.  Perhaps we should ship docker with a default to send messages at the "warn" level.  I also fixed up the audit patch to just send on "start", "stop", "create", "remove".

An admin who can create arbitrary system services could do `ExecStart=/bin/rm -rf /`, and there already wouldn't be anything auditing that "they" deleted the files, right?  Basically if the user has CAP_SYS_ADMIN we've already lost if they are trying to avoid audit.

I say we push GET calls on /json and /version to debug. These aren't changing the system. These aren't events we need to record/audit...

Colin, if the machine is sending its logs off machine, they will at least know that the admin did something to block the messages from going off machine.  I know it is of limited value, but this is the way the CC people think.  I also know that they would know that a the evil admin configured a systemd service and started it up.

I changed the code that does status type calls to go to Debug and the Modify types to go to Info.

	switch action {
	case "info":
	case "images":
	case "version":
	case "json":
	case "search":
	case "stats":
	case "events":
	case "history":
		logrus.Debug(message)
		fallthrough
	default:
		logrus.Info(message)

We are now regression free using docker-1.9.1-4.el7.x86_64

But there is still tons and tons of useless log spam which I think belongs in debug.

time="2015-11-25T17:29:42.292843622Z" level=info msg="GET /version"
time="2015-11-25T17:29:37.153226450Z" level=info msg="GET /containers/json"
time="2015-11-25T17:29:35.494220670Z" level=info msg="GET /containers/669652cdd176af134c4ba37301d4391540a9a6e8518dfd5b17b0b56fa8e1550a/json"

Are all messages seen VERY frequently (40k per hour) when running kubernetes. (16 containers running)

Opened a pull request with docker to fix this issue.

https://github.com/docker/docker/pull/18260

I have also update the 1.9 and 1.10 docker branches on ProjectAtomic with this fix.

Now moved to 
https://github.com/docker/docker/pull/18343

Now moved to 
https://github.com/docker/docker/pull/18343

Merged.  This will be fixed in docker-1.10.  Do we need to back port this into docker-1.9?

The last 1.9 I got from Lokesh is no worse than 1.8. If it's easy I'd like to see it in 1.9. If it's more than 30 minutes work we can certainly live until 1.10.

I can just apply the pull request I originally suggested and be done with it for docker-1.9.

Actually I already did.  Lokesh could you build an updated version of docker-1.9.1 for RHEL and Fedora.

http://brewweb.devel.redhat.com/brew/taskinfo?taskID=10184721

Hi Eric,

Could you have a look at the latest version -23
if make the log quite?

I only test a simple kubectl example which
communicates with docker,it's looks good to me
but hard to build a complicate one to simulate
the real product environment.

This LGTM. I did get some spam on startup that I've not seen before. But I'll file another bug on that. this is VERIFIED

(In reply to Eric Paris from comment #27)
> This LGTM. I did get some spam on startup that I've not seen before. But
> I'll file another bug on that. this is VERIFIED

thanks eric, in docker-1.9.1-23.el7.x86_64, move to verified

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0536.html