If signal is defined in a custom module for a self-updating command. the module never loads

[gsgleason]

Module config:

"custom/test": {
            "exec": "~/bin/date",
            "signal": 1
        }

~/bin/date:

#!/usr/bin/bash
while true; do 
    date
    sleep 7
done

If the signal line is removed, the module loads and updates per the script.

My use case is a custom module that will show the number of updates available, which will also reload after a pacman update with a hook that sends the signal to waybar.

A workaround is to use an interval in the module config and have the executable not loop itself.

Arch Linux
waybar 0.12.0-1
hyprland 0.47.2-2

[RobertMueller2]

This is what the manpage waybar-custom says for signal:
"If no interval is defined then a signal will be the only way to update the module."

So the behaviour you're observing seems to be intended. Perhaps there could be a new feature that provides an option force-exec-on-load or something.

[gsgleason]

This is what the manpage waybar-custom says for signal: "If no interval is defined then a signal will be the only way to update the module."

So the behaviour you're observing seems to be intended. Perhaps there could be a new feature that provides an option force-exec-on-load or something.

I disagree. The wording does not suggest that the two options are mutually exclusive. Also, there is no error in the waybar output related to this. It just silently fails.

[RobertMueller2]

The options are not mutually exclusive. But if you have

    "custom/test": {
            "exec": "./date-test.sh",
            "signal": 1,
        }

custom module will use a waitingWorker, for

    "custom/test": {
            "exec": "./date-test.sh",
            "signal": 1,
            "interval":"once"
        }

(or any other interval) it will use a delayWorker and for

    "custom/test": {
            "exec": "./date-test.sh",
            "signal": 1,
            "restart-interval":5
        }

it will use a continuousWorker. I've tested this with some trace output (could have used a debugger, but I like trace output). As far as I can tell, only the continuousWorker is really suited for continuous script output, the other two kinda expect that the script exits. The first and the second can be woken up by a signal. I don't think anything happens for the signal when using a continuousWorker.

After looking at the other sections of the manpage again, the whole section for interval, restart-interval and signal, matches what I've observed with the configs above and reads technically correct to me. But something that was based on use cases instead might have worked better here. E.g. require explicit worker-type and then say something along the lines of

• use "worker-type": "delay" if you want to execute a script with a given interval. Supports signal, exec-if and exec-on-event.
• use "worker-type": "waiting" if you want to execute a script initially and upon receiving a signal. Supports signal, exec-if and exec-on-event
• use "worker-type":"continuous" if you want to listen for continuous script output.
  and then throw errors for invalid combinations instead of inherently and intransparently choosing different worker types. But someone would have to change that and advocate the fact it would be a breaking change. ;) Perhaps in place of that the manpage could reflect sensible combinations or what triggers which worker/mode.

I think right now your options are:

• use the first example with a non-continuous script. As far as I've observed, it'll initially populate the module and it can then be updated by signal. The deciding portion is that the script exits. Kinda what you want to achieve?
• use the second example with a non-continuous script and any interval (the workaround you already have)

p.S.: The separate implementation for signal without interval was added in #2517. I was wrong about the interpretation of the manpage as far as the initial execution if concerned, but the "only updated by signal" part seems to be intended beyond the initial execution.