Crash on notification settings

Question

Crash on notification settings

jfjallid opened this issue 8 years ago · 25 comments

Whenever I try to access the notification settings the docker container crashes without any error messages. I'm running the container with your example command but with modified values for paths, uid and gid

Answer 1 · 2016-10-30T06:58:15.000Z

Which platform are you running the image on? Crashing without any messages makes me think of a recent Docker bug that could be causing the crash.

Answer 2 · 2016-10-30T07:18:35.000Z

I'm running it on CentOS x64.
Docker version 1.12.1, build 23cf638.

Answer 3 · 2016-10-30T09:36:45.000Z

I've tried running it on Docker version 1.12.3, build 6b644ec and the problem remains.
When I run the developer image instead, the webserver crashes but the docker container keeps running. The webserver crashes with the message "The connection was reset" and no further output in the container log. I'm running the container interactively and after the webserver crashes it just hangs silently without writing anything else to stdout or stderr.

Answer 4 · 2016-10-31T01:53:44.000Z

OK, I'll try and reproduce tonight.

Answer 5 · 2016-10-31T15:33:40.000Z

I'm able to reproduce the issue. There doesn't appear to be any messages in the log or console. I'll try and dig deeper and try and find out what is causing the exit.

Answer 6 · 2016-11-16T22:31:40.000Z

@ressu Any progress on this?

Answer 7 · 2016-12-27T15:55:57.000Z

I'm having a hard time getting this resolved, it feels a lot like an musl compatibility issue. I'm currently trying to narrow down what is actually causing the crash and working backwards from there

Answer 8 · 2017-01-30T13:42:35.000Z

The fixed builds should now be up. Took me a bit longer to get around to fixing this than I expected.. The only solution I could find was to switch away from the Alpine based image to Debian based image.

Answer 9 · 2017-02-05T22:32:27.000Z

Yes, this solved the problem nicely. Thanks!

Answer 10 · 2017-07-22T21:51:41.000Z

@ressu this can be fixed by setting the threading stack size in SickGear. Thus we can continue to use Alpine as the base.

These are the refs to the root cause of the issue:

python-pillow/Pillow#1935
python-pillow/Pillow#1935 (comment)
docker-library/python#211 (comment)
https://github.com/voidlinux/void-packages/issues/4147
https://github.com/voidlinux/void-packages/pull/6889/files

Answer 11 · 2017-07-26T14:17:41.000Z

Cool, I personally prefer Alpine over Debian for the Docker image. Pull requests are welcome, I'm not sure when I'm able to revert PR #8 and test with the new threading stack sizes.

Answer 12 · 2017-07-26T14:30:57.000Z

So I've spoken with @JackDandy and we're working on testing a config directive for specifying the default thread stack size. That way we can revert to an Alpine based docker image in master, and just update the config template to specify the stack size to something large enough to keep it working. I haven't yet managed to test the PR over on kulta regarding this new config setting though.

Answer 13 · 2017-08-10T12:15:40.000Z

Thanks for looking into the fix, however, shouldn't this one still be open ? Took me a little to dig it up is all

Answer 14 · 2017-08-10T13:19:20.000Z

@timm088 I basically investigated and resolved the issue entirely independently before realising it was fixed on master, because there wasn't an open issue :(
@ressu I do think you should make it clearer to people that this is a problem on dev with a change to the dev branches README. And look at my PR/harass @JackDandy for input :-)

Answer 15 · 2017-08-12T10:03:51.000Z

Ok thanks. Would be great if that pr could be linked here, so I can just pulled it myself?

Answer 16 · 2017-08-13T22:54:04.000Z

Checkout the master branch Or view my fork and the dev branch

Answer 17 · 2017-08-14T01:12:36.000Z

Last commit on master was

9c3a158a5df3aea9f438e3038074282e2fbe5f44
Confirmed my alpine docker container has this same commit in Sickgear / Settings / About

Problem still exists for Alpine docker images on current master branch

No problems if it isn't merged yet, I manually configured notifications via config.ini (which for me is mounted into the container each time)

Answer 18 · 2017-08-14T11:09:20.000Z

I can't find the commit you're referring to... This is the latest commit on the master branch:

16a847c

Answer 19 · 2017-08-14T11:10:23.000Z

Sorry, i'm referring to the master branch of Sickgear itself, not the dockerfile

i.e., you said its fixed on master? You mean changed to debian, not actually fixed (i.e, threading stack size fixed)

Answer 20 · 2017-08-14T11:19:38.000Z

If you just want to change the SickGear version to fix this issue, you can use this commit from the current hotfix branch: 70edd5462fca9ebdfc4ffa6caef7708219e79704

Then set the stack_size = 327680 under General in config.ini

Answer 21 · 2017-08-15T12:06:13.000Z

Hotfix branch?
There are only two visible branches...

Answer 22 · 2017-08-15T13:23:16.000Z

Did you actually find the commit I referred to?

Answer 23 · 2017-08-15T13:47:22.000Z

You do realise there is no hotfix branch right?
https://github.com/SickGear/SickGear/branches/all

Guessing hotfix branch is private?

You mean this commit? SickGear/SickGear@70edd54

Answer 24 · 2017-08-16T08:08:16.000Z

https://git.kulta.us/SickGear/SickGear/src/hotfix/0.12.26

That's the right commit yes.

Answer 25 · 2017-08-27T06:16:53.000Z

Merged into master on github now for anyone else that might come across this.
SickGear/SickGear@2c2a5b1