| View previous topic :: View next topic |
| Author |
Message |
ipic
Guru
Joined: 29 Dec 2003
Posts: 407
Location: UK
|
 Posted: Sun Nov 10, 2024 6:06 pm Post subject: Conky: ${fs_.. mountpoint} values not updating |
 |
|
This used to work, but unfortunately I didn't spot when it stopped working, so I can't say what changed to cause this. Same for both conky versions currently in portage.
I have some disk space monitoring lines defined as follows:
| Code: |
${color1}File systems:
${color1}root ${color}${fs_used_perc /}% ${fs_bar 6 /}
${color1}usr ${color}${fs_used_perc /usr}% ${fs_bar 6 /usr}
${color1}var ${color}${fs_used_perc /var}% ${fs_bar 6 /var}
${color1}share ${color}${fs_used_perc /share}% ${fs_bar 6 /share}
${color1}home ${color}${fs_used_perc /home}% ${fs_bar 6 /home}
${color1}ipic ${color}${fs_used_perc /home/ipic}% ${fs_bar 6 /home/ipic}
${color1}ipic-local ${color}${fs_used_perc /home/ipic/.local}% ${fs_bar 6 /home/ipic/.local}
${color1}tmp-portage ${color}${fs_used_perc /var/tmp/portage}% ${fs_bar 6 /var/tmp/portage}
${color1}rsnapshot ${color}${fs_used_perc /mnt/rsnapshot}% ${fs_bar 6 /mnt/rsnapshot}
|
I tried ${fs_free mountpoint} as well, with the same result (i.e. do not update when free space changes)
All the targets are separate partitions (LVM volumes to be exact)
They all show the correct value when I start conky, but then do not change when the space usage of a partition changes.
I monitor the disk space using and can see it change, but conky just stays on the startup values.
All the other things I have conky monitor update correctly, eg
| Code: | ${diskiograph /dev/sda}
${upspeedgraph br0 15,90} ${upspeed br0}
${hwmon 6 fan 1}
|
and so on.
Unfortunately my Googling 'skill' yields no results for this issue.
Has anyone else seen this? |
|
| Back to top |
|
 |
stefantalpalaru
Tux's lil' helper
Joined: 11 Jan 2009
Posts: 77
Location: Italy
|
| Posted: Sun Nov 10, 2024 6:45 pm Post subject: |
|
|
| I'm running conky-1.21.8 where "fs_free" and "fs_used" work properly for ext4 filesystems, but stopped updating for ZFS pools, a few versions back. |
|
| Back to top |
|
|
ipic
Guru
Joined: 29 Dec 2003
Posts: 407
Location: UK
|
| Posted: Sun Nov 10, 2024 7:45 pm Post subject: |
|
|
All my file systems are ext4 
I am on 1.21.7 - perhaps that is it. |
|
| Back to top |
|
|
tomtom69
Apprentice
Joined: 09 Nov 2010
Posts: 253
Location: Bavaria
|
| Posted: Sun Nov 10, 2024 7:51 pm Post subject: |
|
|
Same here, with ext4 file system
My conky config is rather old so I thought it is related to that.
The correspondig line in config is: | Code: |
${color grey}FS SYS: ${fs_free /}/${fs_size /} ${fs_bar 6 /} |
I tried to change "/" to "/dev/sda4" (which is the device for this mount point) but this does not work at all.
The issue appeared with conky update to 1.21.7. The formerly stable version 1.19.8 did not have this issue |
|
| Back to top |
|
|
ipic
Guru
Joined: 29 Dec 2003
Posts: 407
Location: UK
|
| Posted: Mon Nov 11, 2024 9:57 am Post subject: |
|
|
During my morning emerge routine I noticed that | Code: | | ${fs_used_perc /var/tmp/portage} |
was not reporting change either. This is a tmpfs file system.
So, I downloaded the 1.21.8 Appimage from github.
A test using 1.21.8 showed that it reported changes to tmpfs.
A further test showed it reporting changes to an ext4 partition.
It is odd, since this issue is not mentioned in the release notes. Either it was fixed by some other change in version 1.21.8, or something is compiled into the appimage that is not compiled into my installed version 1.21.7 |
|
| Back to top |
|
|
ipic
Guru
Joined: 29 Dec 2003
Posts: 407
Location: UK
|
| Posted: Mon Nov 11, 2024 10:07 am Post subject: |
|
|
Well, closer inspection of the changelog shows I missed this:
| Code: |
src/fs.{cc,h}: Update fs_stats without error spam. by @pghvlaans in #2033
|
The description of the PR says this:
| Code: |
update_fs_stats was recently altered to clear set for all file systems every thirteen seconds, and its update_fs_stat call was removed. This was done to mitigate a longstanding issue whereby repeated errors appeared when updates were attempted for a nonexistent mountpoint. However, before the change, update_fs_stat was only called from prepare_fs_stat and update_fs_stats. In consequence, update_fs_stat is now called for each filesystem only at init time, and no changes are displayed.
|
It goes on to describe the fix that was merged.
So folks, we are not all going mad - this one was real!
Does this warrant a Gentoo bug asking for a version bump? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22648
|
| Posted: Mon Nov 11, 2024 3:18 pm Post subject: |
|
|
If a new version of Conky is available with the fix, and the Gentoo maintainer has not noticed that within a few weeks of the release, then in my opinion, it would be appropriate to file a bug requesting the bump. If there is no release, but the fix is self-contained and easy to backport, I think it would be fine to file a bug asking for a Gentoo -r revision of the ebuild that applies the fix.
For the benefit of readers here, it would be nice to include a link to the PR. Some people can probably work it out from the PR number you cited, but a direct link would be simpler. |
|
| Back to top |
|
|
ipic
Guru
Joined: 29 Dec 2003
Posts: 407
Location: UK
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22648
|
| Posted: Mon Nov 11, 2024 3:51 pm Post subject: |
|
|
| "A few weeks" is not a hard rule. Rather, it is an estimate based on balancing competing goals. One the one hand, you want to inform a maintainer who is unaware of the release, so that it does not languish indefinitely. On the other hand, you want to avoid badgering a maintainer who will handle it without being prompted, but has not yet had time to deal with the bump. Same day bump requests are generally held to be more of a nuisance than a help. Waiting a few weeks is, in my opinion, enough time that if the maintainer were aware, there would be some evidence of that awareness, even if only the maintainer filing a bump bug to record that it needs to be done. |
|
| Back to top |
|
|
ipic
Guru
Joined: 29 Dec 2003
Posts: 407
Location: UK
|
| Posted: Mon Nov 11, 2024 4:12 pm Post subject: |
|
|
Here is a patch that fixes the fs updating issue in the gentoo current version, which is 1.21.7
To apply this patch, copy it into a file called conky-1.21.7-fs-fix.patch (or whatever_you_want_to_call_it.patch), and then place that file in /etc/portage/patches/app-admin/conky-1.21.7
| Code: |
diff --git a/src/fs.cc b/src/fs.cc
index 7593d99..bb55f13 100644
--- a/src/fs.cc
+++ b/src/fs.cc
@@ -79,7 +79,7 @@ int update_fs_stats() {
if (current_update_time - last_fs_update < 13) { return 0; }
for (i = 0; i < MAX_FS_STATS; ++i) {
- fs_stats[i].set = 0;
+ if (fs_stats[i].set != 0) { update_fs_stat(&fs_stats[i]); }
}
last_fs_update = current_update_time;
return 0;
@@ -113,6 +113,7 @@ struct fs_stat *prepare_fs_stat(const char *s) {
}
strncpy(next->path, s, DEFAULT_TEXT_BUFFER_SIZE);
next->set = 1;
+ next->errored = 0;
update_fs_stat(next);
return next;
}
@@ -142,10 +143,14 @@ static void update_fs_stat(struct fs_stat *fs) {
/* bfree (root) or bavail (non-roots) ? */
fs->avail = static_cast<long long>(s.f_bavail) * s.f_bsize;
fs->free = static_cast<long long>(s.f_bfree) * s.f_bsize;
+ fs->errored = 0;
get_fs_type(fs->path, fs->type);
#endif
} else {
- NORM_ERR("statfs '%s': %s", fs->path, strerror(errno));
+ if (fs->errored == 0) {
+ NORM_ERR("statfs '%s': %s", fs->path, strerror(errno));
+ fs->errored = 1;
+ }
fs->size = 0;
fs->avail = 0;
fs->free = 0;
diff --git a/src/fs.h b/src/fs.h
index 16bcafc..41d3a4d 100644
--- a/src/fs.h
+++ b/src/fs.h
@@ -40,6 +40,7 @@ struct fs_stat {
long long avail;
long long free;
char set;
+ char errored;
};
/* forward declare to make gcc happy (fs.h <-> text_object.h include) */
|
This is a verbatim copy from the conky github repository, I take no credit for it whatsoever.
I suggest it's use for anyone who is effected by this issue, while a Gentoo version 1.21.8 is not available. |
|
| Back to top |
|
|
tomtom69
Apprentice
Joined: 09 Nov 2010
Posts: 253
Location: Bavaria
|
| Posted: Mon Nov 11, 2024 9:35 pm Post subject: |
|
|
I also tried to extract a patch but you were faster than me.
Thank you, works perfectly :-) |
|
| Back to top |
|
|
stefantalpalaru
Tux's lil' helper
Joined: 11 Jan 2009
Posts: 77
Location: Italy
|
|
| Back to top |
|
|
|
Portage & Programming
