Need support to enable socket-based activation of glusterd... ref: http://0pointer.de/blog/projects/socket-activation.html When tried to activate glusterd using socket-based activation method, glusterd tries to bind to port 24007 held by systemd and throws following errors: [2015-04-21 18:13:27.352659] I [MSGID: 100030] [glusterfsd.c:2288:main] 0-/usr/local/sbin/glusterd: Started runn ing /usr/local/sbin/glusterd version 3.8dev (args: /usr/local/sbin/glusterd -p /var/run/glusterd.pid) [2015-04-21 18:13:27.382292] I [glusterd.c:1282:init] 0-management: Maximum allowed open file descriptors set to 65536 [2015-04-21 18:13:27.382345] I [glusterd.c:1327:init] 0-management: Using /var/lib/glusterd as working directory [2015-04-21 18:13:27.392716] E [socket.c:823:__socket_server_bind] 0-socket.management: binding to failed: Addr ess already in use [2015-04-21 18:13:27.392753] E [socket.c:826:__socket_server_bind] 0-socket.management: Port is already in use [2015-04-21 18:13:27.392782] W [rpcsvc.c:1589:rpcsvc_transport_create] 0-rpc-service: listening on transport fai led [2015-04-21 18:13:27.392809] E [glusterd.c:1509:init] 0-management: creation of listener failed [2015-04-21 18:13:27.392850] E [xlator.c:426:xlator_init] 0-management: Initialization of volume 'management' fa iled, review your volfile again [2015-04-21 18:13:27.392865] E [graph.c:322:glusterfs_graph_init] 0-management: initializing translator failed [2015-04-21 18:13:27.392878] E [graph.c:661:glusterfs_graph_activate] 0-graph: init failed [2015-04-21 18:13:27.393372] W [glusterfsd.c:1212:cleanup_and_exit] (--> 0-: received signum (0), shutting down [2015-04-21 18:13:27.429586] I [MSGID: 100030] [glusterfsd.c:2288:main] 0-/usr/local/sbin/glusterd: Started runn ing /usr/local/sbin/glusterd version 3.8dev (args: /usr/local/sbin/glusterd -p /var/run/glusterd.pid) [2015-04-21 18:13:27.447571] I [glusterd.c:1282:init] 0-management: Maximum allowed open file descriptors set to 65536 [2015-04-21 18:13:27.447624] I [glusterd.c:1327:init] 0-management: Using /var/lib/glusterd as working directory [2015-04-21 18:13:27.486555] E [socket.c:823:__socket_server_bind] 0-socket.management: binding to failed: Addr ess already in use [2015-04-21 18:13:27.486595] E [socket.c:826:__socket_server_bind] 0-socket.management: Port is already in use [2015-04-21 18:13:27.486624] W [rpcsvc.c:1589:rpcsvc_transport_create] 0-rpc-service: listening on transport failed
[root@localhost system]# cat glusterd.socket [Unit] Description=glusterd server socket [Socket] ListenStream=24007 ListenStream=/var/run/glusterd.socket Accept=no [Install] WantedBy=sockets.target [root@localhost system]# ==================================================================== [root@localhost system]# cat glusterd.service [Unit] Description=glusterd - Gluster elastic volume management daemon Documentation=man:glusterd(8) After=network.target Wants=network-online.target Wants=syslog.target [Service] Type=forking PIDFile=/var/run/glusterd.pid LimitNOFILE=65536 ExecStart=/usr/local/sbin/glusterd -p /var/run/glusterd.pid KillMode=process [Install] WantedBy=multi-user.target [root@localhost system]#
I am not sure if socket activation makes a lot of sense here. Gluster clients may already know what bricks are available. When a Gluster Server reboots, glusterd should start the brick processes. When socket activation is used, glusterd will only start after a connection on the socket (unix socket or tcp port) is detected. I think gluster clients can try to connect to the brick processes without touching any of the glusterd sockets. What is the use-case you are trying to solve here?
GlusterD would anyway start upon reboot. The usecase here is... admin/user has the privilege to enable and start glusterd.socket (on need by basis) and not be bothered about restarting glusterd (In case the process gets killed due to crash or OOM kill or by any other means)... it does get automatically started by next vol info or any other volume command. Failure does not go unnoticed, it is handled by systemd for further diagnosis. Of course we have to document about not using this feature while using quorum.
I am not (yet) convinces this is the right approach. If restarting glusterd after a failure is needed, we can add a Restart=... option to the glusterd.service file. See 'man systemd.service' for more details. Restarting on a crash/OOM might not be a good idea in general, it can well be that something is horribly wrong, and restarting does not give a guarantee that the whole system recovers and becomes usable again.
Yep agree with the `Restart=' option. This is more of an on-demand activation. More of a good to have feature.
Sac - I believe that this BZ is just hanging over with out any activity. In GD1, we're not looking to take this enhancement. I'd suggest to close this bug.
(In reply to Atin Mukherjee from comment #6) > Sac - I believe that this BZ is just hanging over with out any activity. In > GD1, we're not looking to take this enhancement. I'd suggest to close this > bug. Ack! We can close this bug.