Fix not being able to start service because temperature not yet available#27
Fix not being able to start service because temperature not yet available#27y0ast wants to merge 2 commits intogrmat:masterfrom y0ast:patch-1
Conversation
sometimes it takes a while for the temperature of the gpu to become available, leading to ``` FILE_TEMP=$(echo /sys/class/drm/card0/device/hwmon/hwmon?/temp1_input) ``` being empty and the service failing with "invalid hwmon files". I tried to look for a valid service to start after, but it doesn't seem to exist. Alternative to this solution there's a few others: - Restart (with 5 sec delays) until service starts successfully. - Add a path watcher for `/sys/class/drm/card0/device/hwmon/hwmon?/temp1_input` The first could lead to an infinite restart loop, the second muddles logic from the `amdgpu_control` script and the service.
y0ast
changed the title
|
Hi, thanks for reaching out. I'm not going to merge a |
y0ast
changed the title
|
I've now updated it to just do a restart on failure. Would you be open to merging that? Despite your intention of this code being only a demo script, it is now directly mentioned in the Arch wiki: https://wiki.archlinux.org/index.php/Fan_speed_control#fancurve_script Therefore it would be nice if the default setup at least starts on most machines. |
mik13ST
left a comment
mik13ST
left a comment
There was a problem hiding this comment.
I suggest using StartLimitIntervalSec with the StartLimitBurst directive to prevent infinite restart loop. See man systemd.unit. I don't know what values to choose for these two directives. It might be necessary to make some measurements of when the hwmon files are accessible.
It still wouldn't as good as waiting for the file to exist though.
Yes, I am facing the same issue.
|
|
||
| [Install] | ||
| WantedBy=multi-user.target | ||
| WantedBy=default.target |
There was a problem hiding this comment.
Why is this necessary? Setting the restart properties does not require changing the WantedBy property, right? The ArchWiki says default.target is usually a symlink to graphical.target which is different from multi-user.target.
There was a problem hiding this comment.
I believe default.target is a bit more common for these type of services. Happy to change it back if @grmat expresses interest in merging this.
3 participants
sometimes it takes a while for the temperature of the gpu to become available, leading to
being empty and the service failing with "invalid hwmon files".
I tried to look for a valid service to start after, but it doesn't seem to exist. Alternative to this solution there's a few others:
/sys/class/drm/card0/device/hwmon/hwmon?/temp1_inputThe first could lead to an infinite restart loop, the second muddles logic from the
amdgpu_controlscript and the service.Open to suggestions. The fix suggested in #25 is not sufficient for me, but this works.
fixes #25