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
Here output from systemd-analyze critical-chain and systemd-analyze blame.
I think that now glusterd start too early (before networking)
[root@ovirt01 tmp]# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@"
character.
The time the unit takes
On Mon, Nov 9, 2015 at 9:06 PM, Stefano Danzi 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
>> [glusterd-store.c:4243:glusterd_resolve_all_bricks] 0-glusterd:
>> resolve brick failed in restore
The above log is the culprit here. Generally this function fails when
GlusterD fails to resolve the associated host of a brick. Has any of the
node undergone an IP change during the upgrade
4 matches
Mail list logo