search

matryer / xbar

Put the output from any script or program into your macOS Menu Bar (the BitBar reboot)
https://xbarapp.com
MIT License
17.56k stars 643 forks source link

`signal: killed` error #735

Closed alisterburt closed 3 years ago

alisterburt commented 3 years ago

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.

image

matryer commented 3 years ago

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

alisterburt commented 3 years ago

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 commented 3 years ago

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

matryer commented 3 years ago

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

leaanthony commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Thanks @zessx - will try that!

matryer commented 3 years ago

@alisterburt did @zessx's approach work?

alisterburt commented 3 years ago

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

Romack commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Please try the latest release to see if this helps.

TiagoRibeiroCA commented 5 months ago

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 commented 5 months ago

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

TiagoRibeiroCA commented 5 months ago

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