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@xxxxxxxx> 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
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
