Open ByteDrummer opened 1 year ago
Hi,
I can confirm that I am facing the same issue as @ByteDrummer, with more or less the same config:
postswitch
script, I kill all polybar instances and then relaunch them for each connected monitor by running a polybar ... &
to branch out the processautorandr
from 1.12.1
to 1.13.3
, the postswitch
script seems to be correctly executed, but the polybars disappear shortly after.autorandr 1.12.1
fixes the issue (I've also tried downgrading to 1.13.2
, but this version seemed to be buggy on my end)I was experiencing similar behavior: polybar disappearing after a few seconds when launched from ac autorandr postswitch script. Fixed it by replacing the launch-my-polybar.sh
call in the postswitch script to i3-msg exec launch-my-polybar.sh
. This ensures the polybar process is owned by i3 and won't be killed when autorandr finishes.
That's smart. I'm on bspwm though which I don't think has a command like that.
Just saying that I'm having the same problem. This is my launch script which is called in postswitch
and polybar appears then disappears about 2-3 seconds later. I've tried debugging this but my only conclusion is that, despite the disown
in my launch script, autorandr is cleaning up all its child processes. I have no problems if I run polybar outside of autorandr.
I have the same issue as @gfarrell and I think this commit causes it. The commit results in a change of the udev rules that are installed (at least on my system; I installed autorandr
using the Arch repo package). I debugged the Makefile and when doing a make install
, the variable TARGETS
has the content autorandr autostart_config systemd udev manpage
, while MAKECMDGOALS
has the content install
. Thus systemd
is not found in the variable anymore. This causes autorandr
to be directly invoked instead of the systemd unit. But that also means that the processes that are started are killed again, which is not supported by a udev rule directly. Instead it is recommended to trigger a systemd unit from the udev rule so that the new processes are kept alive (i found this information here.
@phillipberndt I am happy to proved a pull request with a fix but I am not sure what the best way would be to fix the issue. One way would be to revert the aforementioned commit but that seem to break something else (Gentoo related). Another way would be to check dynamically if the system uses systemd, instead of relying on the build target (if that is possible). Or maybe this should be fixed by the packager of the Arch repo package by providing the correct build target?
Edit: I found that there is already a check in the Makefile if systemd is present. If that is the case it is added to DEFAULT_TARGETS
. I created a PR (https://github.com/phillipberndt/autorandr/pull/345) that uses this to fix the issue.
If anyone wants a quick fix, just edit /usr/lib/udev/rules.d/40-monitor-hotplug.rules
from
ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr//bin/autorandr --batch --change --default default"
to
ACTION=="change", SUBSYSTEM=="drm", RUN+="/bin/systemctl start --no-block autorandr.service"
Makes sense. Thanks, merged!
Polybar doesn't launch with autorandr 1.13.3 and 1.13.1 but works fine in 1.13.2. It seems to have something to do with https://github.com/phillipberndt/autorandr/commit/b08336a3b942c0c5a33d565d9baa441fe69d58f0.
This is how I'm running polybar in the postswitch:
When power cycling my monitor, polybar terminates and then runs again, with its output indicating that it launches successfully, but isn't visible. If I add
sleep 10000000
to the end of the script, the issue doesn't occur. This means that branched processes are closed after the end of the postscript is reached.I have also reported this issue to polybar.