Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote: > It seems there is very weird stuff going on there: it fails because > in afr_inode_refresh_subvol_cbk (after a lookup), we have a valid > reply from brick 0 with op_ret = 0. > > But the brick 0 server process was killed. that makes no sense. Looking at a kernel trace I can now tell that the brick0 server process indeed gets a SIGKILL, but then glusterd spawn a new process for brick0 that answers the requests. glusterd log confirms that: first it starts the two bricks; [glusterd-pmap.c:227:pmap_registry_bind] 0-pmap: adding brick /d/backends/brick0 on port 49152 [glusterd-pmap.c:227:pmap_registry_bind] 0-pmap: adding brick /d/backends/brick1 on port 49153 -> Killing brick0 [glusterd-handler.c:4388:__glusterd_brick_rpc_notify] 0-management: Brick nbslave73.cloud.gluster.org:/d/backends/brick0 has disconnected from glusterd. -> And here it restarts! [glusterd-pmap.c:227:pmap_registry_bind] 0-pmap: adding brick /d/backends/brick0 on port 49152 -> test terminate and kill all bricks: [glusterd-pmap.c:271:pmap_registry_remove] 0-pmap: removing brick /d/backends/brick0 on port 49152 [glusterd-pmap.c:271:pmap_registry_remove] 0-pmap: removing brick /d/backends/brick1 on port 49153 Hence it ould be a glusterd bug? Why would it restart a brick on its own? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@xxxxxxxxxx _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
