Upgrading from my prelease version, the user service was not restarted. Maybe this is correct - I don't see how systemd could reasonably restart an arbitrary bunch of user services. There is no practical problem, because the utility is so tiny.
On my desktop with 5400rpm rotating media, it complains about I/O pressure a lot. So it works as advertised.
BZ#1832623 Review Request: psi-notify - Alert when your machine is becoming over-saturated
On rebooting, psi-notify is started for every user account, whether logged in or not. Maybe having some running with no gui is why I started getting core-dumps after booting. Each user psi-notify crashes after initial load, then is restarted by systemd.
@sdgathman thanks for continuing the review even after the package is created! Please file a bug and I'll take a look. It could be related to the different presets between Fedora 31 and 32 -- apparently even without using the systemd scriptlet in the spec, the service still ends up enabled.
What does systemctl --user status psi-notify say? I'll also get a Fedora 31 container or VM to test. Maybe the solution is to pre-ship a preset that disables psi-notify by default... but I'm not sure how user units get started if the user is not logged in. That is odd.
@sdgathman, also what's your default boot target? If it's non-graphical that could be causing the issue. I'll suggest to upstream to switch to graphical.target instead of default.target. As for being enabled by default, I suspect it could be because you had the -1.fc31 package previously installed.
Boot target is graphical. It works normally (module occasional crashes, on which systemd restarts it). It may be a feature of user services that they are started even when you aren't logged in.
This update has been submitted for testing by salimma.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
Upgrading from my prelease version, the user service was not restarted. Maybe this is correct - I don't see how systemd could reasonably restart an arbitrary bunch of user services. There is no practical problem, because the utility is so tiny.
On my desktop with 5400rpm rotating media, it complains about I/O pressure a lot. So it works as advertised.
On rebooting, psi-notify is started for every user account, whether logged in or not. Maybe having some running with no gui is why I started getting core-dumps after booting. Each user psi-notify crashes after initial load, then is restarted by systemd.
Generating a backtrace for submitting the crash report fails both for retrace server and locally.
@sdgathman thanks for continuing the review even after the package is created! Please file a bug and I'll take a look. It could be related to the different presets between Fedora 31 and 32 -- apparently even without using the systemd scriptlet in the spec, the service still ends up enabled.
What does
systemctl --user status psi-notifysay? I'll also get a Fedora 31 container or VM to test. Maybe the solution is to pre-ship a preset that disables psi-notify by default... but I'm not sure how user units get started if the user is not logged in. That is odd.@sdgathman, also what's your default boot target? If it's non-graphical that could be causing the issue. I'll suggest to upstream to switch to graphical.target instead of default.target. As for being enabled by default, I suspect it could be because you had the -1.fc31 package previously installed.
Boot target is graphical. It works normally (module occasional crashes, on which systemd restarts it). It may be a feature of user services that they are started even when you aren't logged in.
This update can be pushed to stable now if the maintainer wishes
This update has been submitted for stable by bodhi.
This update has been pushed to stable.