Description of problem: Directory for metrics wasn't created automatically after sending USR2 signal or when installing RPM package. Version-Release number of selected component (if applicable): 4.1 Steps to Reproduce: - install glusterfs from RPMs - send USR2 signal to gluster process - metrics don't appear Expected results: Directory for metrics creates gluster process or RPM package. Additional info: After sending USR2 signal: [2018-08-30 15:56:10.268011] E [MSGID: 101024] [monitoring.c:244:gf_monitor_metrics] 0-monitoring: failed to open tmp file /var/run/gluster/metrics/gmetrics.6OjyJa (No such file or directory)
This is not a packaging bug. It's not the responsibility of packaging (i.e. the glusterfs.spec(.in) file) to make directories. Either the `make install` or the process — at runtime — should create the directories, just as already happens for (/var)/run/gluster/{bitd,glustershd,nfs,quotad,scrubshared_storage,snaps,vols} The packaging already "owns" (/var)/run/gluster, and all files and directories under it. (But the various distribution packagers may provide work-arounds until upstream catches up.)
Amar, can the code create the directory in case it is missing? (/var)/run/gluster has permissions for the gluster group to create contents there. The directory will automatically be cleaned on reboot. Alternatively this could be done through a /etc/tmpfiles.d snippet.
While adding the code, I thought of creating it automatically, but later felt, it can be done by application needing the 'metrics' too. (Like glustermetrics creates this directory). For 4.1.x series, I guess it should be just documentation bug, and we should be creating the directory in master for now, if everyone feels that is the right thing.
(In reply to Amar Tumballi from comment #3) > While adding the code, I thought of creating it automatically, but later > felt, it can be done by application needing the 'metrics' too. (Like > glustermetrics creates this directory). I think that whatever generates the metrics should create the directory. Unless gluster gets instructed to place the metrics somewhere the application chooses (volume option?). > For 4.1.x series, I guess it should be just documentation bug, and we should > be creating the directory in master for now, if everyone feels that is the > right thing. This feels like a rather crucial failure, the missing directory prevents metrics from being stored. It would be just as easy and quick to fix the problem in 4.1.x as documenting a fix? I'd be in favour for a backport :)
REVIEW: https://review.gluster.org/21141 (monitoring: create dump dir if it doesn't exist) posted (#1) for review on master by Amar Tumballi
COMMIT: https://review.gluster.org/21141 committed in master by "Amar Tumballi" <amarts> with a commit message- monitoring: create dump dir if it doesn't exist Fixes: bz#1624006 Change-Id: Ie78be72e2492cd02c1376852bb90f1e6661d9bea Signed-off-by: Amar Tumballi <amarts>
glusterfs-4.1.5-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
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-6.0, please open a new bug report. glusterfs-6.0 has been announced on the Gluster mailinglists [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] https://lists.gluster.org/pipermail/announce/2019-March/000120.html [2] https://www.gluster.org/pipermail/gluster-users/