Apologies for breaking into the discussion, but it seems to fit here: From what I’m seeing, the two fixes for Process.GetProcesses () are already included in Mono’s current stable (4.0.4.1).
At the very least, I don’t seem to have an issue with updating Sonarr (from latest master to latest develop, that is).
Is there something in particular I can test or look for? Reason is I’d like to update the Synology Mono package at some point (as a beta release first so we can get some feedback), but I don’t necessarily want to break people’s setup 
How can I be condescending markus? I asked you a long time ago why it does not work and until now you did not explain, so I am being reasonable to assume that you don’t care if you don’t care to explain. How is that being condescending? Go on my posts list and see me praising the app several times and thanking the developers. Now just because I am making one very valid complaint I am being condescending or is it you that do not know how to take criticism? By the way, I was not blowing any smoke. It is perfectly fine to assume that bugs can mean vulnerabilities, I am not saying that all bugs lead to vulnerabilities but many vulnerabilities stem from bugs/bad programming and you can say that I am wrong but it will not change that fact. I just want my app to be updated! I am frustrated every time I look at Sonarr’s update list and see fixes that I cannot get because it is not updating. Why can’t you guys please liaise with the package maintainer on QNAP to get this issue sorted? I am not the only one having this problem and you would know how to explain much better than I do since you are a developer. You could accomplish much more spending 5 minutes to write a concise message than I would accomplish by sending a long-winded message full of unsure information. Thanks for your effort but please put yourself in our shoes, you can get analytics I am sure, so you know how many people on QNAP are using your app, we’re all disappointed, please help.
Hey, Dr_Bean.
Interestingly, it looks like the second commit was also applied in earlier mono versions, as early as 4.0.1. The particular bug that I described earlier should only affect specific OSes, since it depends on what kind of syscalls the OS supports (from what I can see the KERN_PROC syscall is BSD specific). That might explain why you’re not seeing it on syno.
My concern is that mono changed code in the api between mono and the OS with respect to processes, without diving into it in detail I can’t ascertain exactly what changed. But i’ll venture a guess.
The code that invokes the KERN_PROC syscall was changed from a fixed max of 400 processes to a dynamic allocated one.
The syscall is first invoked without an actual buffer, and expects the syscall to return the buffer size required.
Subsequently the buffer gets allocated and the syscall invoked with the buffer, so the kernel can populate the buffer with process details.
The first commit implements this behavior, but had a bug… it doesn’t actually pass the buffer to the kernel in the second syscall. (in other words, it was never tested).
The second commit fixes that problem by passing the buffer along as intended.
If both commits are currently in the mono version available for qnap, then it could be that either mono’s assumptions about the syscall behavior is wrong, or the implementation on the OS side. Someone would have to look and compare FreeBSD and QNAP kernel source code to figure that out. Or someone could revert those two commits, see if it goes back to normal.
As for 4.x on syno, wouldn’t it be an idea to compile 4.0.4 as beta package and get a couple of regulars to test it for a month (or two)? Our experience is that any mono release is subject to regressions that only show themselves on specific usage patterns, so some duration testing is advised.
This is pretty condescending:
Markus was saying that he would love to see a list of security issues. Wow. That came from a developer. Why do people update apps? It’s because of bugs, and bugs often mean vulnerabilities, I never though that I would have to explain this to a developer.
Its a mono bug. Stephane (sp?) is aware that mono 4.0 doesn’t work for Sonarr’s updater, which is why 3.10 is recommended.
dont use Qmono 4.01, use only Qmono 3.10, Qmono 4.10 avoid the update running fine, it doesnt not finding the process to kill
(http://forum.qnap.com/viewtopic.php?f=320&t=109449&start=60#p486978)
and on our forums:
An update script instead of using Sonarr’s updater might work (its been a part of Sonarr for some time, but I’m not sure how many people use it) maybe @qoolbox can help with creating it specifically for QNAP:
The script takes in the following args:
ProcessID
Update folder (where the new files are)
Executing Application (full path to NzbDrone.exe - quoted if it contains spaces)
Arguments from when Sonarr was launched
The script will need to stop Sonarr, copy the files from the update folder to the proper folder, then start Sonarr again.
You’re right, those fixes were already present in Mono 4.0.1.0. Seeing as I don’t use QNAP, I can’t do much about that package, but reverting the code might be an easy way to verify the issue.
I was already planning on publishing the Syno package on the beta channel, and we’ll keep it there for a while. Just wanted to make sure there’s not a generic issue with Mono 4.x. I’ll pass on the feedback we get.
Thanks for the info 
I did not mean to be condescending at all, so apologies if you felt that way but it was not my intention.
Yes he is aware, but if you knew that the newest version had fixed it, why not tell him? I already did though, let’s see if he will update the package. I was only able to do it after I found out yesterday when reading the other guy’s message.
I noticed a script option. I just have no idea how to do it. Just wish that somebody with experience would do that. I help people, just not when I don’t know how. If I knew, I would be involved in fixing it.
Thanks.
That is not correct imo.
The Mono version that Stephane has packaged (4.0.1.0 from what I can tell, correct me if I’m wrong) already had that fix. Still, people run into issues with it.
That part of the Mono code hasn’t been touched since from what I can see, so it seems unlikely that packaging the latest stable will make a difference.
But let’s say you do, and the issue persists. I’d suggest to verify those code changes are indeed causing the problem, and if so, open a bug on Mono’s bugtracker. Imo, that’s where that part of the discussion belongs.
Thanks. I don’t know how to do that or what to explain, because I am not a developer, I have no experience with scripting/programming. I am just a user. I can understand some technical stuff but not programming level or how to analyse scripts. If I knew how to do it, I would be immediately going there and do it myself, trust me on this. I hate to be here humiliating myself asking for help but I have no other option =/ If you know how to do it, would you please kindly do it? It would help all QNAP users, not only myself. Thanks very much.
Fwiw, you seem to be approaching this like you urgently need to upgrade to 4.x. Unless you’re a .net/mono developer or maybe a poweruser and need 4.x for a specific reason, that’s not true. Just stick with 3.x for Sonarr. It works perfectly fine with that version, and that won’t change very soon.
If you’re asking me to make an effort to fix the Mono package for Qnap, sorry, but no. For one, I don’t own a QNAP, and secondly, I’m spending my spare time on Synology packages
Stephane uploaded the newest version of Mono and it seems to have fixed the issue, now Sonarr is updating. About installing an older version, no way… I just don’t run old software unless it’s not being maintained anymore. Fair enough if you don’t want to do it, it’s your time. Thanks.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.