signal: killed error

[alisterburt]

Thanks for xbar, such a fun app to play with!

I've been toying with a few custom plugins on an M1 macbook air running Big Sur (11.2.1) and keep running into a signal: killed error - I'm not sure exactly what causes it. If it helps, I also keep seeing #710.

[matryer]

Hey @alisterburt thanks for reporting this. It looks like an issue with the plugin itself, can you link to it?

[alisterburt]

Hi @matryer - it's a simple script I wrote myself which can be found at https://gist.github.com/alisterburt/15280eae3d03ccb28e45713c3e10aeed

Since restarting I've only seen this issue very rarely, usually after waking the mac up from sleep

[ghost]

I got the same issue. It might be caused by plugin scripts, it's difficult to debug with this message...

[matryer]

@leaanthony Do we think we know what was causing this?

[leaanthony]

No idea off the top of my head. If the app is still running then it would seem to me like context cancel is being called and the command killed.

[Cueball]

I get this regularly with my (changed-and-not-definitely-improved) Homebrew plugin. I'm also running 4 other plugins, which never have any issues. I can post the "WIP" plugin script if that's helpful.

I'd rewrite the plugin to be more robust in handling error conditions, but I'm not sure where the "signal: killed" is coming from - if there's a debug log somewhere for each plugin that I can read, that'd be great (I'm sure I looked in the doco ages ago for that but didn't see anything relevant then; I'll re-explore the doco when I get a spare moment this evening.)

[ghost]

I get this regularly with my (changed-and-not-definitely-improved) Homebrew plugin. I'm also running 4 other plugins, which never have any issues. I can post the "WIP" plugin script if that's helpful.

I'd rewrite the plugin to be more robust in handling error conditions, but I'm not sure where the "signal: killed" is coming from - if there's a debug log somewhere for each plugin that I can read, that'd be great (I'm sure I looked in the doco ages ago for that but didn't see anything relevant then; I'll re-explore the doco when I get a spare moment this evening.)

Which language are you using in your Homebrew plugin? Any modules are you using in it?

[Cueball]

Plugin is currently written as a shell script; I think the original is a bash script and so I haven't altered the shebang from /bin/bash - but I don't think it's using any particular bashisms. Nothing fancy about it.

I noticed it was still using the bash= style rather than shell= so I fixed that just now; will post if that seems to make any difference (I don't expect it to tho'.)

TBC I'd planned to eventually rewrite it in Ruby and maybe publish that version, so I'd rather put more effort into the Ruby version than fix this one.

[zessx]

Try to use response = requests.get(request_url, timeout=1), it seems requests it trying IPv6 first and if you don't specify a timeout your script will fail before IPv4 was tried.

[alisterburt]

Thanks @zessx - will try that!

[matryer]

@alisterburt did @zessx's approach work?

[alisterburt]

@matryer - no errors so far but they were very intermittent anyway, will report back if it crops up again! 🙂

[Romack]

Is anyone still having this issue? I have a script that fails most of the time via xbar, but runs successfully on the command line (return code of 0). It takes around 1 minute to complete so perhaps that is related to the issue?

Any ideas or thoughts on how to debug this issue?

[Cueball]

I still do, but it's also still inconsistent. Maybe once or twice a day? Same deal - literally never fails from CLI; only from within Xbar.

As mentioned before, I was planning to convert my shell-based script to Ruby, in the hope that it would be neater, faster and avoid any timeout issues. Haven't got to that yet though...

[matryer]

There is currently a timeout of one minute for plugins to run. I'm going to set this to 2 minutes to see if that helps.

[matryer]

Please try the latest release to see if this helps.

[TiagoRibeiroCA]

I don't know if this ship has sailed already but, @matryer any chance the timeout could be increased to 3 or 4 mins? I have a gitlab MR fetcher, but I'm fetching hundreds of groups, each with several hundred projects/repos, with dozens of MR's each, so I get the signal:killed error, although it works like a charm via terminal

[leaanthony]

I think it might be possible to add a config for this, but it would affect all plugins.

[TiagoRibeiroCA]

I consider 3 or 4 mins very acceptable. But ideally there would be a way to override this so anyone would use their desired timeout. Because on my specific case, 2 mins is just impossible, even using cache, the first request has to scan thousands of projects and MRs under them /:

EDIT: Actually, even if the base timeout on xbar source code is 4 or 5 mins even, anyone on their personal plugins can add a smaller timeout on their requests. So I don't imagine this would cause much hassle to current users