So far, so good. It’s been running for 24 hours and it picked up last night’s downloads. Thanks!
I moved 3 posts to a new topic: No tasks running after startup
Working fine again for me, thanks all.
I think i had mine working for a few days after the recent update to fix this issue, looks like back again for me.
Here is some logs.
https://externalz.homelinux.com/Public/nzbdrone.txt
The first log only has trace logging at the end, but the 2nd shows the CheckForFinishedDownload task running regularly.
What makes you think the issues is reoccurring? Are tasks not running?
I realized when episodes weren’t downloading, then i checked my Tasks tab and it showed every task hadn’t been completed in over a day.
I then copy pasted my first log, enabled trace and restarted. Then followed it up with another log in case you needed more.
I will leave trace on over the next week to see if it does it again.
Update,
Looks like it started doing it rather quickly again,
Another Log
https://externalz.homelinux.com/Public/nzbdrone_3.txt
Version
2.0.0.3212
Mono Version
3.10.0 (tarball Wed Nov 5 12:50:04 UTC 2014)
Update #3,
It must have restarted on its own?
Which kernel are you running?
3.13.0-54-generic
Ubuntu 14.04
Edit: the update#3 was a result from a OS restart. Disregard that 
If you try to manually run one of the tasks, does it run?
@Taloth round 2! Depending on the answer for the above question this might be scheduler related.
Still waiting on it to play up again, i will post the results when it does.
@markus101 I don’t think I’m ready for a round 2. Still got headaches from the last mono debugging.
I had this issue before the previous fix, and just now it has popped up again. I didn’t have trace logging enabled before, but I do now so I will post a log next time it happens.
I WAS able to run the tasks manually from the UI, and they run perfectly fine once.
OS info:
kernel 3.13.0-53-generic
Ubuntu 14.04.2 LTS
Still no faults so far…
As i run autoupdates i decided to check my kernel version again and its now 3.13.0-55-generic
Not sure if this helps…
So far it seems like its happening with mono 3.10 on Ubuntu 14.04, I don’t think there has been another OS/mono combination reported so far.
A memory dump of the process would be the helpful.
Is anyone on mono 4.0.1 seeing this issue? (I don’t want everyone to go and upgrade, as we’d like to see if we can determine why its happening).
I’m running 4.0.1 on CentOS 6 and have been good to go since the fix was made.
Is something like this what you’d need for the memory dump? Should it be done just after starting Sonarr or just whenever?
@markus101 Memdump on mono is useless, no way to load it into the debugger.
So I recommend you first absolutely confirm it’s hanging, via log and db copy, otherwise we’ll be wasting a lot of time and headaches investigating.
Also get those affected on develop, coz you added a bit more logging there. (never cherrypicked those)
Next is the frequency of it hanging. That greatly affects how we can best approach the issue.
One options is to add yet more logging.
Other would be to enable --trace:… to trace the classes/methods related to the scheduler and cmdqueue, just the bare minimum, otherwise you’ll end up with insane trace logs over a long period.
Finally we have two debug options:
First is attaching gdb to the running process, but inspecting variables will be hard labor, all cmdline.
Second is remotely via MonoDevelop remote debugger feature, not sure of the bandwidth requirements, but gives easier access to stacks and variables. It’s not possible to attach it while running coz it needs a couple of cmdline params on mono to set up. So option 2 probably doesn’t work well when the issue happens only once a week.
Even thinking about it gives me headaches.
@Taloth As to frequency, with me it happens at every restart. Tasks run once and never again, this includes tasks set to run once a minute.
As to making the the trace options more specific: Is that something I have to do or you guys have to push out a new version for?
Switching to develop: Is that something people affected by this problem should be doing by default, or only once requested by you guys?
I’m able to give remote access to developers if needed, please PM me so we can discuss further details.
That whole post was primarily intended for markus, just to some up what’s ahead of us. Wasn’t expecting users to dive into those details. Especially the --trace settings, those aren’t easily done.
You mean, if you restart Sonarr none of the tasks run, ever until you trigger em manually? So, basically, you can reproduce it instantly by restarting Sonarr?
Anyway, if it’s reproducible like that, then I would like to take a look at it. Not today though.