thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', gui/src/app/header.rs:55:56 about lact

[Big-FG]

Discovered what is causing it

The junction temp change that i had suggested previously is causing the gui to crash for some reason.

reverting this fixes it

a7d203c

[Big-FG]

I threw together a quick patch just to test it as i had started at reverting the GTK migration and bump deps from the same day.

Just making sure im reverting ONLY the junction patch

test.txt

Im assuming its getting something back it doesnt like?

EDIT: The plot thickens, upon a reboot this one fails too but if i restart the daemon its ok, so it may not be the patch after all and my restarting the daemon testing builds is what fixed it

[Big-FG]

I managed to fix this for myself by changing the systemd unit

[Unit]
Description=AMDGPU Control Daemon
After=graphical.target

[Service]
ExecStart=/usr/bin/lact-daemon

[Install]
WantedBy=display-manager.service

This seems to work consistently across reboots, why all the sudden it wasnt working anymore I dont know as Im not familiar enough with systemd stuff. Im not sure this is a good solution though but it has it workin in the mean time. This could be because i had to disable early kms because otherwise my monitor has a fit.

[ilya-zlobintsev]

Sometimes there seems to be an issue where the systemd unit starts too early in the boot process, before the SysFS is properly initialized. I hoped specifying After=multi-user.target would fix it, but I guess not. I'm not sure about

[Install]
WantedBy=display-manager.service

though, since the service doesn't have much to do with the display manager, but I guess it does have to be WantedBy by something.

[Big-FG]

Yeah Im not so sure about

[Install]
WantedBy=display-manager.service

I was trying to think of something around graphical.target but before login and it seemed like an OK choice but as for it being a real solution I dont think so. Im not positive a systemd unit needs a wantedby though as some of them dont have it but I only mildly get how systemd units work so i cant say for certain.

Im not sure if systemd-user-sessions.service is a viable late boot option. It doesnt really have anything to do with it like before but it does ensure that the daemon starts after the sysfs is initialized and before user login.

[ilya-zlobintsev]

I would also prefer to avoid depending on grapahical.target or display-manager.service as that wouldn't work properly on headless systems. Considering that the bug seems to be some kind of race condition from my experience, a crappy but probably functional workaround would be to just add a couple of seconds of waiting before the unit starts.

Something like this:

ExecStartPre=/bin/sleep 2

[Big-FG]

Ill give that a try and see if that works out, thatd probably be much better than doing something that doesnt work for headless.

[Big-FG]

Yeah after multiple reboots this seems to solve the issue, before that even just one reboot would force me to have to restart the daemon but after 5 reboots no issues.

ExecStartPre=/bin/sleep 2

I didnt even think of that even though i already do that with GDM x3 was making it more complicated than i needed to changing wantedby and such.

[ilya-zlobintsev]

@Big-FG I've updated the lact-git package in the AUR to include this, hopefully it fixes the issue.