Description of problem: In Geo replication, 3 directories - .processing, .processed and .current which has crawl related change logs are stored under /var/run/gluster/<master>/<slave-url>/<brick-hash>. /var/run/gluster* is not picked by sosreport and on reboot content of that Directory might wiped out. So we can move it to some other location Version-Release number of selected component (if applicable): How reproducible: always Actual results: logs are stored under /var/run/gluster* Expected results: move logs under /var/lib/misc Additional info:
REVIEW: http://review.gluster.org/7375 (gsyncd / geo-rep: FSH recommended log locations) posted (#1) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/7375 (gsyncd / geo-rep: FSH recommended log locations) posted (#2) for review on master by Kotresh HR (khiremat)
REVIEW: http://review.gluster.org/7375 (gsyncd / geo-rep: FSH recommended log locations) posted (#3) for review on master by Kotresh HR (khiremat)
REVIEW: http://review.gluster.org/7375 (gsyncd / geo-rep: FSH recommended log locations) posted (#4) for review on master by Aravinda VK (avishwan)
REVIEW: http://review.gluster.org/7375 (gsyncd / geo-rep: FSH recommended log locations) posted (#5) for review on master by ajeet jha (ajha)
COMMIT: http://review.gluster.org/7375 committed in master by Venky Shankar (vshankar) ------ commit ec5d64eafcd77b1746b83173de16f7ec742af7a6 Author: Venky Shankar <vshankar> Date: Wed Mar 19 19:32:15 2014 +0530 gsyncd / geo-rep: FSH recommended log locations Upgrading "working_dir" on the fly is a bit unclean yet (though it works) as currently config upgrade does not support "old" values to be expanded by using configuration variables. Change-Id: I44ed65c281f2e0ce3b6b467addc5c1c88ac674e7 BUG: 1077516 Signed-off-by: Venky Shankar <vshankar> Signed-off-by: Kotresh H R <khiremat> Signed-off-by: Aravinda VK <avishwan> Signed-off-by: Ajeet Jha <ajha> Reviewed-on: http://review.gluster.org/7375 Tested-by: Gluster Build System <jenkins.com>
A beta release for GlusterFS 3.6.0 has been released. Please verify if the release solves this bug report for you. In case the glusterfs-3.6.0beta1 release does not have a resolution for this issue, leave a comment in this bug and move the status to ASSIGNED. If this release fixes the problem for you, leave a note and change the status to VERIFIED. Packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update (possibly an "updates-testing" repository) infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-September/018836.html [2] http://supercolony.gluster.org/pipermail/gluster-users/
Of note that on Ubuntu at least, /var/run is a symlink to /run which is a tmpfs filesystem and of limited size on smaller hosts (such as AWS machines). As such can easily fill up the filesystem causing geo-replication to fail as well as problems with other services. Glad this fix is in 3.6.0, thanks much guys!
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.6.1, please reopen this bug report. glusterfs-3.6.1 has been announced [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://supercolony.gluster.org/pipermail/gluster-users/2014-November/019410.html [2] http://supercolony.gluster.org/mailman/listinfo/gluster-users