to temporary fix this problem I changed [Unit] section in glusterd.service file: [Unit] Description=GlusterFS, a clustered file-system server After=network.target rpcbind.service network-online.target vdsm-network.service Before=vdsmd.service Il 10/11/2015 8.02, Kaushal M ha scritto:
On Mon, Nov 9, 2015 at 9:06 PM, Stefano Danzi <s.danzi@hawai.it> wrote:
Here output from systemd-analyze critical-chain and systemd-analyze blame. I think that now glusterd start too early (before networking) You are nearly right. GlusterD did start too early. GlusterD is configured to start after network.target. But network.target in systemd only guarantees that the network management stack is up; it doesn't guarantee that the network devices have been configured and are usable (Ref [1]). This means that when GlusterD starts, the network is still not up and hence GlusterD will fail to resolve bricks.
While we could start GlusterD after network-online.target, it would break GlusterFS mounts configured in /etc/fstab with _netdev option. Systemd automatically schedules _netdev mounts to be done after network-online.target. (Ref [1] network-online.target). This could allow the GlusterFS mounts to be done before GlusterD is up, causing them to fail. This can be done using systemd-220 [2] which introduced support for `x-systemd.requires` option for fstab, which can be used to order mounts after specific services, but is not possible with el7 which has systemd-208.
[1]: https://wiki.freedesktop.org/www/Software/systemd/NetworkTarget/ [2]: https://bugzilla.redhat.com/show_bug.cgi?id=812826