QOS Graphs not working in 175

If @otadr had the graphs working in CU174 and they are giving the error message in CU175 then that looks like there is a bug present.

To confirm, I started QOS up on CU175 and after 30 mins I still had the following status


The /var/log/rrd/ directory had the following files

drwxr-xr-x 4 root root 4.0K Jun 13 20:22 .
drwxr-xr-x 18 root root 4.0K Jun 13 11:56 …
-rw-r–r-- 1 root root 745K Jun 13 20:40 class_1-1_red0.rrd
-rw-r–r-- 1 root root 745K Jun 13 20:40 class_2-1_imq0.rrd
drwxr-xr-x 3 root root 4.0K Mar 6 2017 collectd
-rw-r–r-- 1 root root 29K Jun 13 20:40 hddshutdown-sda.rrd
-rw-r–r-- 1 root root 29K Jun 13 20:40 hddtemp-sda.rrd
drwxr-xr-x 2 root root 4.0K Apr 24 00:00 wio

Then I installed CU174 on a vm system and started QOS the same way and virtually straight away I had a graph, even if there was no content on it yet.


The /var/log/rrd/ directory contained the following files:-
Screenshot_2023-06-13_20-42-25

So in CU175 there are many files missing which in CU174 are created straight away when QOS is started.

I would suggest that @otadr raises a bug for this issue.

https://wiki.ipfire.org/devel/bugzilla
https://bugzilla.ipfire.org/

Your IPFire People Email Adrress and Password will act as your login credentials for the IPFire Bugzilla.

6 Likes

Since I only write English in front of a translator,
and I haven’t posted the error report yet, I’ll ask someone knowledgeable to do it, so it’s meaningful. Thanks

1 Like

@otadr I encourage you to do the job yourself using chatGPT from https://chat.openai.com/

I composed a short message in my native language, requesting the Language Model (LLM) to write a persuasive message to you in English on my behalf. The intention was to encourage you to prepare a comprehensive bug report by providing instructions to the LLM in your own language. Additionally, I suggested including two supporting arguments for this approach. Please note that the instructions were hastily written in less than a minute IN MY NATIVE LANGUAGE, resulting in their subpar quality. The following text is what the AI has generated based on those instructions.

Dear IPFire User,

I understand that you feel hesitant about preparing a bug report due to your reliance on a translator. However, I have a suggestion that might help you overcome this challenge. I recommend creating an account with OpenAI and using ChatGPT 3.5 in your native language, just as I am doing now.

There are two significant advantages to this approach. Firstly, using ChatGPT 3.5 will provide you with high-quality text output that closely matches the language you input. This will help ensure the accuracy and clarity of your bug report. Secondly, by observing how ChatGPT formulates responses, you can gradually improve your English language skills, absorbing sentence structures and expanding your vocabulary along the way.

I encourage you to give it a try. Begin by asking ChatGPT 3.5 to switch to English and then compose your message following the instructions provided. You can rely on ChatGPT to assist you throughout the process, just like I am doing now. Embracing this approach will not only help you create a more effective bug report but also enhance your English language proficiency.

Best regards,
[Your Name]

I am back, this is cfusco using his own poor English skills. For your own best interest, do the bug report yourself. You will quickly learn how to use this new tool to compose good quality messages in a new language, to write code in any computer programming language and ultimately to make you in a better position in life. Remember what in the AI community they say, quote:

You will not lose your job to an AI. You will lose your job to someone else using an AI

I want to leave you with a final thought. There are many short-comings to OpenAI. To mention just two, they generate code which is subpar at best and wrong at worst. Also, Microsoft will exploit its users and violate their privacy, you can be certain of that. However, this is the way forward. Learn to use these tools, and learn to work around their limitations. Follow the development of LLM and as soon as you are comfortable, install one to run LOCALLY, without giving up your privacy to multinationals companies.

Bug has been reported by @otadr

https://bugzilla.ipfire.org/show_bug.cgi?id=13150

3 Likes

thank you I’ve already seen

2 Likes

The same here. Since the update from 174 → 175,
the old rrd-files are all there and have a current date and time stamp, but no new added content.


2 Likes

Ah. When I did my test on my vm testbed I saw that the graphs were still present but didn’t notice that no new data was being added.

Could you add your input into the bug in the IPFire Bugzilla - see post #9

1 Like

OK, done
Actually looks like this:

1 Like

Another “me too” reply. I had QoS and graphs working fine on 174, then updated to 175 and they stopped displaying. Interestingly, QoS appears to continue working for me, perhaps because I already had the rules set up prior to updating. I say that based on running speed test and buffer bloat tests and getting similar results to 174. So for me, it appears as if the graphs just stopped displaying anything.

Just that, wondering if somebody else is having the same issue

  • Error -
    Error in RRD::graph for qos device redo: opening ‘/var/log/rrd/class_1-101 red0.rrd’: No
    such file or directory
    (qos.cgi, redo, hour)

Hi, I am trialing IPFire mainly for its cake feature, brand new install IPFire 2.27 - Core Update 175
Proxmox VM
Upon installation I only configured QoS and error shown above appears.
QoS settings are understood by the wiki, I simply set it to 50000/20000 and hit preset save.
Did a search before posting, of the dozen or so similar posts, there only appears to be 1 similar to mine, however the post went unresolved.
Cant really give anymore info other than fresh install and changed one thing, the QoS.

Hall @tidehunter

Welcome to the IPFire community.

See thread https://community.ipfire.org/t/qos-graphs-not-working-in-175/9885 for the topic covering what you have experienced and this specific post https://community.ipfire.org/t/qos-graphs-not-working-in-175/9885/9 for the link to the bug report which gives details of the status.
Fix has been implemented into Core Update 176 which is currently in Testing phase.

3 Likes

I posted about this not too long ago on 174

Qos rrd has me stumped

With no answers for a fix.

Several people have already reported in the bug report that the fix in CU176 Testing has resolved the problem for them.

Please test Core Update 176 Testing and report back the results.

4 Likes

To give an overall picture of what happened.

There was an earlier bug raised Bug#13075 in Core Update 174.

The root cause for the problem was that a change occurred in the tc package used to create the data for QOS. A change was made to the regex for tc which solved the problem but then tc was updated upstream to fix the problem and so the graphs again were not properly created when the updated tc was implemented in Core Update 175.

The regex change was then reverted in Core Update 176 which then allows the upstream corrected tc package to properly deal with the data for the graphs.

3 Likes

See:

1 Like

I activated QOS at my gateway a day ago. It is “IPFire 2.27 (x86_64) - Core-Update 175”. I activated preset configuration. QOS status is green, RUNNING. I cannot see RRD graphs, I see only error. Screenshot:

[root@ipfire ~]# ll /var/log/rrd/class_*
-rw-r--r-- 1 root root 762152 Jul  8 14:24 /var/log/rrd/class_1-1_ppp0.rrd
-rw-r--r-- 1 root root 762152 Jul  8 14:24 /var/log/rrd/class_2-1_imq0.rrd

And I see other issue. When I press STATUS button, I see new page with a lot of text but there is no button to return to the main QOS view… :frowning:

When I press button add parrentclass, I see form with buttons “SAVE” and “RESET” but I miss “CANCEL” to return to the main QOS view (without any modification)… :frowning:

the graphs should appear later, when enough data has been collected.

Please see this thread started 25 days ago.
https://community.ipfire.org/t/qos-graphs-not-working-in-175/9885

A bug has been raised on that issue. There is a link in that thread plus to another bug report.
Fix for those bugs has been created and merged and is in Core Update 176 Testing.
Users experiencing this problem have confirmed that the fix applied in Core Update 176 testing has fixed the problem.

Core Update Testing is currently expected to be released early in this following week. (10th Jul onwards)

5 Likes

I confirm that Core Update 176 fixed the issue. I had to restart QoS to see the graphs…

After upgrade to 176 and restart of QoS:

[root@ipfire ~]# ll /var/log/rrd/class_*
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_1-101_ppp0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_1-102_ppp0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_1-103_ppp0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_1-104_ppp0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_1-110_ppp0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_1-120_ppp0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_1-1_ppp0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_2-1_imq0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_2-200_imq0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_2-203_imq0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_2-204_imq0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_2-210_imq0.rrd
-rw-r--r-- 1 root root 762152 Jul 12 13:32 /var/log/rrd/class_2-220_imq0.rrd
4 Likes