Polybar not launching after power cycling

[ByteDrummer]

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:

#!/bin/bash

# Terminate already running bar instances
killall -q polybar

# Wait until the processes have been shut down
while pgrep -u $UID -x polybar >/dev/null; do sleep 1; done

MONITOR=$(xrandr | grep primary | sed 's/ .*//') polybar --reload top &

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.

[glostis]

Hi,

I can confirm that I am facing the same issue as @ByteDrummer, with more or less the same config:

• In my postswitch script, I kill all polybar instances and then relaunch them for each connected monitor by running a polybar ... & to branch out the process
• When upgrading autorandr from 1.12.1 to 1.13.3, the postswitch script seems to be correctly executed, but the polybars disappear shortly after.
• Downgrading back to 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)

[SijmenHuizenga]

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.

[ByteDrummer]

That's smart. I'm on bspwm though which I don't think has a command like that.

[gfarrell]

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.

[pdeubel]

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"

[phillipberndt]

Makes sense. Thanks, merged!