I have downloaded and install the static-linked docker 1.6.1
from this site, and run it on RHEL 7.1
:
[root@localhost bin]# ./docker -d
WARN[0000] Udev sync is not supported. This will lead to unexpected behavior, data loss and errors
INFO[0000] +job init_networkdriver()
INFO[0000] +job serveapi(unix:///var/run/docker.sock)
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
INFO[0000] -job init_networkdriver() = OK (0)
INFO[0000] Loading containers: start.
INFO[0000] Loading containers: done.
INFO[0000] docker daemon: 1.6.1 97cd073; execdriver: native-0.2; graphdriver: devicemapper
INFO[0000] +job acceptconnections()
INFO[0000] -job acceptconnections() = OK (0)
INFO[0000] Daemon has completed initialization
I can see there is a warning: "Udev sync is not supported. This will lead to unexpected behavior, data loss and errors
", and after checking the docker
source code, I find the warning log is from deviceset.go:
func (devices *DeviceSet) initDevmapper(doInit bool) error {
......
// https://github.com/docker/docker/issues/4036
if supported := devicemapper.UdevSetSyncSupport(true); !supported {
log.Warnf("Udev sync is not supported. This will lead to unexpected behavior, data loss and errors")
}
log.Debugf("devicemapper: udev sync support: %v", devicemapper.UdevSyncSupported())
......
}
The devicemapper.UdevSetSyncSupport
is like this:
// UdevSyncSupported returns whether device-mapper is able to sync with udev
//
// This is essential otherwise race conditions can arise where both udev and
// device-mapper attempt to create and destroy devices.
func UdevSyncSupported() bool {
return DmUdevGetSyncSupport() != 0
}
// UdevSetSyncSupport allows setting whether the udev sync should be enabled.
// The return bool indicates the state of whether the sync is enabled.
func UdevSetSyncSupport(enable bool) bool {
if enable {
DmUdevSetSyncSupport(1)
} else {
DmUdevSetSyncSupport(0)
}
return UdevSyncSupported()
}
I can see the reason is enabling udev
sync failed. How can enable udev
sync successfully?
Update:
After checking the disassembly code of dm_udev_set_sync_support
:
(gdb) disassemble dm_udev_set_sync_support
Dump of assembler code for function dm_udev_set_sync_support:
=> 0x0000000000a3e4e0 <+0>: repz retq
End of assembler dump.
It is a empty function and does nothing, not mention set sync support. Does this mean this static-built docker binary is no-use?
I can't reproduce your issue; I get the following:
(gdb) disassemble dm_udev_set_sync_support
Dump of assembler code for function dm_udev_set_sync_support@plt:
0x0000000000403420 <+0>: jmpq *0xda8c92(%rip) # 0x11ac0b8 <dm_udev_set_sync_support@got.plt>
0x0000000000403426 <+6>: pushq $0x14
0x000000000040342b <+11>: jmpq 0x4032d0
Do yourself a favor: Ignore the builds that docker.io does, and get Docker directly from RHEL. It's available in the Extras channel. While it will usually be a few weeks behind upstream releases (e.g. 1.6 instead of 1.7) it is also well-tested and guaranteed to actually work.
Revising my original answer after some useful feedback:
You have to use a dynamic binary: "The issue of course being that with a statically linked binary, udev sync is impossible, and as such can cause corruption issues. This was difficult for RedHat (who maintains the devicemapper driver) to pinpoint because they use a dynamically linked binary (which they provide in their repos).
Just after the 1.7.0 release docker started providing rpms and debs with dynamically linked binaries from the main install script @ get.docker.com (and apt repos to match). With these binaries udev sync is supported and devicemapper should work fine."
Docker has fortunately changed its repositories to provide dynamic binaries since the OP was created.
来源:https://stackoverflow.com/questions/30209642/how-can-enable-udev-sync-successfully-in-docker