How can enable udev sync successfully in docker?
Asked Answered
K

2

11

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?

Knacker answered 13/5, 2015 at 8:33 Comment(0)
R
1

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.

reference: https://github.com/docker/docker/issues/13179

Reprobative answered 18/3, 2016 at 14:46 Comment(0)
S
0

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 <[email protected]>
   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.

Strengthen answered 9/7, 2015 at 23:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.