FS#41338 - [docker] Faulty service file

Attached to Project: Community Packages
Opened by nfnty (nfnty) - Friday, 25 July 2014, 00:53 GMT
Last edited by Sébastien Luttringer (seblu) - Saturday, 26 July 2014, 15:10 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

docker.service is missing a line:

Requires=docker.socket

Seems to be an upstream bug from the 1.1.2 release. In the master branch contrib/init/systemd/socket-activation/docker.service has the missing line.

Additional info:
* package version(s)
1:1.1.2-1

Steps to reproduce:

systemctl start docker
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Saturday, 26 July 2014, 15:10 GMT
Reason for closing:  Fixed
Additional comments about closing:  docker-1:1.1.2-2
Comment by Doug Newgard (Scimmia) - Friday, 25 July 2014, 01:51 GMT
Looks like this was fixed in master, but not in whatever branch the release was cut from.
Comment by Dave Reisner (falconindy) - Friday, 25 July 2014, 19:57 GMT
This can't possibly be right. Services don't require socket units. Sockets are used for on-demand activation and xinetd-style per-instance processes. What is fixed by adding this line?
Comment by nfnty (nfnty) - Friday, 25 July 2014, 20:07 GMT
The docker daemon requires a socket, for its API ,to be running at start.
Comment by Dave Reisner (falconindy) - Friday, 25 July 2014, 20:13 GMT
That doesn't answer my question, so let me rephrase: a socket unit only serves to activate a service unit. Since docker.socket doesn't explicitly use the "Service" directive in its [Socket] definition, it can only possibly activate docker.service. If docker.service is started, why do you need to start docker.socket when the service is already activated?
Comment by nfnty (nfnty) - Friday, 25 July 2014, 20:32 GMT
If you want to have the service enabled (started at boot), then you need to have the socket already activated, because docker won't start without it.
Comment by nfnty (nfnty) - Friday, 25 July 2014, 20:34 GMT
Same thing if you just start the service without starting the socket first.
Comment by Dave Reisner (falconindy) - Friday, 25 July 2014, 21:24 GMT
So, you're saying that docker.service starts in such a way that it expects a well-named socket to already exist? That doesn't make the unit in master any less wrong:

1) Requires doesn't ensure any ordering. So, docker.socket could start after docker.service, leading to a startup failure.
2) Lousy enable behavior. If docker is started in such a way by docker.service that it *requires* /run/docker.sock to already exist, then the .service should have Also=docker.socket in the [Install] section, and not the current WantedBy directive.
Comment by Dave Reisner (falconindy) - Friday, 25 July 2014, 21:25 GMT
I'm not a docker user, so I don't particularly care about what happens here, but it seems misguided to backport a fix that isn't a fix at all.
Comment by nfnty (nfnty) - Friday, 25 July 2014, 23:22 GMT
Yep. Seems like both Also=docker.socket and After=docker.socket should be added to docker.service then.
Comment by Sébastien Luttringer (seblu) - Saturday, 26 July 2014, 14:58 GMT
https://github.com/docker/docker/pull/7257

Loading...