Closed apprehensions closed 3 years ago
I have had the same problem, where you able to fix it by just applying the other patch or do I have to completely redo dwm?
~~Ah, I made a minor typo.😅 This is happening because I encoded the block index in the output rather than the signal. That's why clicking on the second block is sending signal 1 to dwmblocks, which kills it as it is not handled. Let me fix this up real quick.~~
As pointed by wael, this is because dwmblocks-async
doesn't handle SIGUSR1. You'll need to patch dwm
for handling this. dwm-flexipatch
does mention something about this.
You basically update this function in dwm
source.
https://github.com/bakkeby/dwm-flexipatch/blob/master/patch/bar_dwmblocks.c#L29
@Pyxels all i had to do was change
sigqueue(dwmblockspid, SIGUSR1, sv);
to
sigqueue(dwmblockspid, SIGRTMIN+dwmblockssig, sv);
~temporary soluton~
Thanks that fixed the crashing bug. Though now every click is counted as two, do you have the same problem?
Thanks that fixed the crashing bug. Though now every click is counted as two, do you have the same problem?
no, but can i have the script used so i can see if i can produce the same problem?
~note the fix above is only a temporary solution.~
#!/bin/sh
case $BLOCK_BUTTON in
1) notify-send "🖥 CPU hogs" "$(ps axch -o cmd:15,%cpu --sort=-%cpu | head)\\n(100% per core)" ;;
2) setsid -f "$TERMINAL" -e bpytop ;;
3) notify-send "🖥 CPU module " "\- Shows CPU temperature.
- Click to show intensive processes.
- Middle click to open bpytop." ;;
6) "$TERMINAL" -e "$EDITOR" "$0" ;;
esac
sensors | awk '/Core 0/ {print "🌡" $3}'
This for example. ~Im also having issues with the ordering of the blocks.~ I created a new issue for that (#5) But don't waste too much time on it, I can look into it later by myself or just use the older version which worked fine for me.
This is not a bug. dwmblocks-async
assumes you've patched dwm
with the statuscmd patch, as mentioned in the README, which doesn't depend on SIGUSR1. Therefore it doesn't handle SIGUSR1, which causes it to die when some process sends it that signal.
Simple solution for this is to patch dwm
with the latest statuscmd patch, which doesn't use SIGUSR1.
is there a reason to use SIGRTMIN over SIGUSR1? currently rebuilding my whole dwm build just to fix this really dumb location issue, i tried to move around the update signals and it didn't help.
clicking on statusbar/module makes dwmblocks-async crash with code 138 output:
user-defined signal 1 dwmblocks
this happens when used with my modified dwm build + default dwm only patched with dwm-statuscmd-status