[Bug]: graph fails to display

[BETLOG]

What happened?

I'm stunned, but despite the diskio* displaying text digits, the diskiograph* do not display anything. Surely I am just overlooking something....

TEST.conf.txt TEST.sh.txt

• rename minus the .txt
• conky --config=/$DOWNLOADFOLDER/TEST.conf

You may need to specify a known-active disk= in TEST.sh

Note that substituting $disk with /dev/sd\<i> in the echo also fails.

Version

conky 1.18.0 compiled 2023-02-20 for Linux x86_64

Which OS/distro are you seeing the problem on?

Ubuntu

Conky config

as above attachment

Stack trace

No response

Relevant log output

No response

[bi4k8]

I can reproduce with latest git. Specifically, the graph object is visible (with its outlines), but I don't see lines moving across it over time. I occasionally see a sliver taking up the entire right edge of the graph, but it disappears on the next frame.

If I take the output of your script and paste it into the conky config, then the graph does update as expected.

I think what's happening is that, because the ${diskiograph} object is in the output of ${execp}, a new graph is created every frame. When there is disk I/O, the new graph object has no history to set its scale, so it appears as a full-height sliver on the rightmost edge. On the next update, if there is no I/O, the new graph object will look empty.

The reason for this behavior is that the configuration fragment produced by ${execp} could vary arbitrarily between executions, so conky does not attempt to correlate objects in the output of ${execp} across frames and maintain their state the way state is maintained for objects in static parts of the configuration. I don't think there's a good way to have things behave the way you might expect here (as any heuristic to match dynamically-generated objects across iterations will leave someone unhappy), but the documentation here could definitely be clearer about the pitfalls of including stateful objects in the output of an ${execp} object.

[BETLOG]

I understand. I probably should have thought of that.

Given that for a while I had execi 10s on conky ticking at 1.0s I would have expected to see 10 seconds worth... maybe I wasnt paying attention then....maybe that would be a fix: instead of destroying all things each conky tick, make a special case to retain that data for the duration of the execi... but then i guess the graph would still get wiped at the end of the execi anyway.

Can you (anyone) think of a painless way around this? I guess something cumbersome like bash assessing local drive mounts and assembling a bigass lua-string for the drive layout, which also points to other pre-generated scripts or commandstrings to do the data gathering, sed all of that into a template.conf which generates actual conky.conf and then start conky.

No wonder it always seems like user posted .conf examples are lacking innovation; we have to get into layers of scripts-scripting-scripts before anything very funky can happen. (thats just an observation, not a criticism of conky).