Bug 1624006 - /var/run/gluster/metrics/ wasn't created automatically
Summary: /var/run/gluster/metrics/ wasn't created automatically
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: 4.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Amar Tumballi
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-30 16:08 UTC by Pavel Znamensky
Modified: 2019-03-25 16:30 UTC (History)
4 users (show)

Fixed In Version: glusterfs-6.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-26 16:27:38 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Pavel Znamensky 2018-08-30 16:08:39 UTC
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)

Comment 1 Kaleb KEITHLEY 2018-09-04 13:44:34 UTC
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.)

Comment 2 Niels de Vos 2018-09-10 12:22:30 UTC
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.

Comment 3 Amar Tumballi 2018-09-10 12:56:20 UTC
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.

Comment 4 Niels de Vos 2018-09-10 13:24:06 UTC
(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 :)

Comment 5 Worker Ant 2018-09-10 14:02:56 UTC
REVIEW: https://review.gluster.org/21141 (monitoring: create dump dir if it doesn't exist) posted (#1) for review on master by Amar Tumballi

Comment 6 Worker Ant 2018-09-27 03:04:14 UTC
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>

Comment 7 Fedora Update System 2018-10-02 19:29:51 UTC
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.

Comment 8 Shyamsundar 2019-03-25 16:30:33 UTC
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/


Note You need to log in before you can comment on or make changes to this bug.