Red Hat Bugzilla – Bug 771925
[glusterfs-3.3.0qa19]: glusterd should not assume that within a second statedump will be taken
Last modified: 2015-10-22 11:46:38 EDT
Description of problem:
glusterd which takes care of issuing SIGUSR1 to the brick processes for taking the statedump will write the options mentioned by the user (given through cli) about what all information has to be dumped to the statedump file.
This is the piece of code from glusterd_brick_statedump function of glusterd which does the above functionality.
snprintf (dumpoptions_path, sizeof (dumpoptions_path),
glusterd_set_dump_options (dumpoptions_path, options, option_cnt);
gf_log ("", GF_LOG_INFO, "Performing statedump on brick with pid %d",
kill (pid, SIGUSR1);
ret = 0;
It can be seen from the code that, glusterd issues the SIGUSR1 signal to the brick process for taking statedump. But after that it sleeps for 1 second and then removes the file which contains the options provided by user.
The glusterfs process which receives the SIGUSR1 signal will look into the /tmp/glusterdump.%s.options file and dumps the information that have been mentioned in that file.
Instead of glusterd assuming the statedump would have been taken in 1 second and unlinking it would be good if the glusterfs process itself deletes the file after dumping the the information.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
http://review.gluster.org/2585 : it would need more of review cycles, but keeping in POST to indicate that some effort has been done on the issue.
REVIEW: http://review.gluster.org/2585 (statedump: glusterd should not unlink the options file for statedump) posted (#2) for review on master by Raghavendra Bhat (firstname.lastname@example.org)
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.
If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.