jumperalex
-
Posts
2000 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by jumperalex
-
-
over a year running kingston ecc with no heatsink/spreader ... no problems. No unexplained locksup etc. My airflow is not bad but not massive either. In fact I specifically tried to design my system with as little airflow as needed because I have a dog ;-) I'd say the airflow specifically around my single chip is pretty low.
-
Let's dispel the nonsense. Our Privacy Policy is a section of a larger Policies statement:
Wow look at that. Who would have thought to look in the About:Policy section of a company's webpage for their policies? It is just so crazy of a place that it almost makes sense. Not as much sense as a witch hunt, but ... yeah ... moving on.
-
yeah you might have other issue i guess. Best i can say is a clean slate start as a test. keep your old session and appdata, but first eliminate any question that there is something bad left over from your old install.
I do know though that rtorrent still might benefit from some work on a graceful shut down given how my trackers claim I'm seeding from multiple locations if I don't stop all my torrents before a restart. I don't have that problem with my windows client when i shut it down because it isn't having its virtual plug pulled.
-
yup. of course the easier way if you already have to do something manual is to select all your torrent, click stop, wait, then kill the docker as usual [shrug]. That should have the same effect of notifying the tracker and ensuring your state is clean. but of course then you have to restart the torrents and that can be annoying if you have choosen not to seed everything you have.
just a though for how little I know it is worth
-
So I upgraded, copied over my session folder and despite having to check a handful of torrents, all seemed to be good.
However my settings don't seem to be saving, and I restarted it and it had to check a (large) handful or torrents again. So, again, it seems something is not saving with some files, like the state of a bunch of torrents. Are there some permissions that need to be fixed?
Here is my run command: docker run -d --name="rutorrent" --net="bridge" -e TZ="America/Denver" -e HOST_OS="unRAID" -e "PUID"="99" -e "PGID"="100" -p 8085:80/tcp -p 51413:51413/tcp -p 6881:6881/udp -v "/mnt/user/downloads/":"/downloads":rw -v "/mnt/user/":"/unraid":rw -v "/mnt/cache/appdata/rutorrent":"/config":rw linuxserver/rutorrent
permissions are all or nothing, all of your torrents would behave the same if that were the case.
i suspect it's more to do with the nature of docker itself , stop / restart the container on some instances can be likened to basically pulling the plug on a running computer.
Sparkly I can't tell, are you this dockers dev / maintaner?
Was looking at wrong Git ... I see that you are sooooo
Would it be possible to modify the shutdown command to include a stop of all torrents with a wait period? that would have two benefits 1) give rtorrent a chance to notify the trackers and 2) let rtorrent itself set the torrent's state correctly
I don't think I'm telling you anything new but the start of my research leads me here:
https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/
The next question of course is, what does rtorrent need for a graceful shutdown
And sheesh I should just wait to write this stuff but I'm impatient and like to record what I learn in steps ...
rtorrent wants to see a SIGINT sent.
https://bbs.archlinux.org/viewtopic.php?id=118686
Here I go again ... thinking ... is this even controllable by the container? I feel like this might be more of an unRaid GUI issue for bonienl. He might need to make it possible for the docker author, or the user, to edit what is sent when we click the STOP option in the Docker UI.
This guys docker https://github.com/kfei/docktorrent has a note
docker stop can gracefully shutdown rTorrent if you give it more time by docker stop -t 120 (which means 120 seconds to time out). -
Tom, I can predict the future. Did you know that?
I suggest your responses here so far, and any future ones on this topic, be consolidated into a single, closed, sticky post in the announcement thread. I believe it will save you a lot of headache based on my predictions of the future when the next beta/rc cycle happens. Or sooner
-
so.....
reinstalled plex yesterday (delete image + container, deleted appdata/plex and all it's contents, install from scratch).
worked fine for about 1/2 a day, then froze. restart the docker, worked for a few hours. came back again tonight and it's frozen a 2nd time, restarting give the error above.
no problems seen with unraid or the other dockers, everything seems to be fine.
that sounds like you are running out of memory / storage space. Are you sure you are not pointing any parts of the docker at either a very small drive. image, or in memory /tmp folder?
-
Its been a long time since I dove into this topic so I might be missing the obvious. Looking at that chart I have to ask;
Are we looking at diminishing returns here? I'm wondering if memory usage and/or operational reads during the parity check are being impacted negatively from using higher values than needed? The curve seems to level out around 1920. From the variance in data I wonder if a practical value that would be 1920 where it appears you will get the same performance for the lowest value.
Absolutely, you're spot on regarding diminishing returns. That's why in my script I'm checking for the "Thriftiest" value, which is the lowest md_sync_window that returns at least 95% of maximum tested speed. (yes, I know that's an arbitrary threshold, but gotta draw the line somewhere, right?)
From the same test run that produced those charts, here's what my script reported:
The Fastest Sync Speed tested was md_sync_window=3392 at 131.6 MB/s Tunable (md_num_stripes): 6784 Tunable (md_sync_window): 3392 Tunable (md_sync_thresh): 3391 Tunable (nr_requests): 8 This will consume 547 MB with md_num_stripes=6784, 2x md_sync_window. This is 157MB more than your current utilization of 390MB. NOTE: Adding additional drives will increase memory consumption. The Thriftiest Sync Speed tested was md_sync_window=832 at 126.2 MB/s Tunable (md_num_stripes): 1664 Tunable (md_sync_window): 832 Tunable (md_sync_thresh): 831 Tunable (nr_requests): 8 This will consume 134 MB with md_num_stripes=1664, 2x md_sync_window.
The "Thriftiest" value (832) was significantly lower than the value you chose (1920), and saves a ton of memory.
It might be that 95% is too low of a threshold for the Thriftiest value. The value you chose is 99.6% of the maximum speed observed.
Or maybe I need to change my algorithm to report the leading edge of the peak, instead of the absolute peak. I could look for the lowest value that gives 99%+ of peak observed speed, which would have returned 1408, or 99.5% which would give 1856.
I still like to test for and report absolute maximums, but your absolutely right about using a lot of memory for very little gain.
-Paul
yup, I'm out of the loop
95%, 99.6%, 98% ... I guess the questing is what IS the real impact of all that memory usage? Because if it doesn't really matter, 99% seems good. If it does, then 95% seems like the place to draw the line. Either way, awesome work. -
Its been a long time since I dove into this topic so I might be missing the obvious. Looking at that chart I have to ask;
Are we looking at diminishing returns here? I'm wondering if memory usage and/or operational reads during the parity check are being impacted negatively from using higher values than needed? The curve seems to level out around 1920. From the variance in data I wonder if a practical value that would be 1920 where it appears you will get the same performance for the lowest value.
-
Every single product out there has the potential for security patches that are not pushed to the current release version for X time while they are being tested in Beta/RC.
If you want to debate the length of X for a vulnerability related to its likelihood and consequence (i.e. the definition of risk) Ican get on board with that. I know it is a hot button with you and I've often agreed with you in other threads. But a blanket statement that you have to be on the Beta/RC train to get all patches isn't black and white.
-
you may need to update to the latest RELEASE, but you do not need to update to the latest BETA or RC unless you intentionally jump on that path. And when you do, because maybe you really want to be a part of the discussion to drive change, then you better understand the risks and limits.
And perhaps be prudent and make sure you have a way back to the most recent stable release for a production server. Read: wanna try new hardware that is only functional in Beta/RC, do it on a test server, accept the risk, or don't do it.
-
Who's to say that in future, this kill-switch won't be used to enforce a blanket subscription policy which rendered all existing licenses (for v4, 5, 6) invalid. Just a thought.
Is there anything LT can say that will make your above statement no longer possible?
Is there a world where, if LT had not yet implemented this functionality in the Beta/RC, your above statement is not still possible?
I mean, who's to say they won't [insert literally any reasonable or unreasonable thing here].
You seem to want / need iron clad immutable declarations where none are either possible or realistic.
-
At what point is an RC not an RC?! This is madness and have never seen anything like that in the 'real-world'. But please, LT - answer the question(s) posed here.
When it is published as a final relase. Is that some how different in your experience?
What data are you collecting? (A file by file breakdown will do to begin with)
A fair question. One Im' pretty sure has been answered long ago but I don't have the time or patience to search for it so yeah, it would be nice for LT to state it again
Why do you need to collect it (reasonably?)
This has been answered. Not liking or believing the answer will not change the answer nor I suspect will a restatement of the answer change anyone's opinion
Can I opt out yet remain an active part of shaping the future of unRAID (i.e. part of the BETA program without allowing a kill-switch on my box?)
Let's take a wild guess at this shall we ... .
DRM preventing my box from booting (BETA OR NOT) is UNACCEPTABLE. The fact that there has been no word from LT on this yet is UNACCEPTABLE. Guys, sort out your PR - please! It's a running joke!!
I don't like DRM either. Simple solution, don't run Beta or RC releases
If Apple, Google, Microsoft or Oracle pulled a similar stunt it would be front page news. I implore you to at the very least respond to your paying customers ASAP. This is shady stuff, suited more to EA than LT. Please sort it out. Like, yesterday.
Apple, Google, Microsoft or Oracle do pull similar stunts ALL THE TIME. And in some cases it ends up on the front page, in other cases it doesn't. You know when it doesn't hit the front page? When they do it on their pre-release channels because everyone knows they don't get to run that forever. Stop creating a false equivalency between LT's policies in the Beta/RC channel vs. the final release channel. It is not shady. It was announced a long time ago. It is stated in every Beta/RC release note, and they have stated they will not screw over their existing paying customers if they decide to institute such a policy in the final release channel. You choosing not to hear or believe that cannot be changed with another restatement.
-
The issue I have is I must run the betas/RC to support the hardware I want to use. I want to run a NVMe SSD cache, so I have enough SATA ports available for my plans. That means I can't run 6.1.9.
So, saying "don't run RC" doesn't help me.
Well, basically I've turned off my UnRAID box, and I'm using a Windows 10 machine with a Drobo plugged in to it. I might move back to UnRAID. Maybe.
Sure it helps you. You shouldn't be trying to run hardware that isn't supported on a final release unless you are willing to accept the well stated consequences and limitations of running Beta/RC. It is really that simple. You WANT to run that hardware and to support that WANT LT has started the process to officially support it. That process isn't complete until they officially release it.
Until that time you shouldn't be using it in a production system that can't handle being down. Had you not moved on to hardware that exceeded the support of the last official release of unraid you wold not have any problems.
-
I am not sure it is as clear cut as beta/RC. The last time this was asked LT "reserved the right" to keep it in the live product. (Too busy to find the quote).
This is what you were referring to:
Quote
Will this requirement for Internet still be present in 'Final'? If so, I will, regrettably, have to remain on v6.1.9 or investigate alternative storage solutions.
As of today I can say "no", but we have to reserve the right to change things it it makes business sense. But you can be assured of this: we will never screw over our existing customers.
This is what has me nervous, if it's not really about preventing piracy then how would it ever make business sense?
sadly this makes not as simple as "asked and answered"
I think it great that some people are okay with this, and we can have a civil discussion here about it, but again I'd really just like an official answer from LT themselves.
But see it is asked and answered and there is no clarifying info to be had until such time as they decide it makes business sense and then tell us about it.
They have stated what their reasons and intentions. As is their right, they also stated that they may change their mind if it makes business sense. If they do, and we don't like it, we vote with our dollars. If enough votes are cast "NAY" such that it makes business sense to change back I am pretty sure they will do what is in their business interests.
As to it not being about piracy and it thus not making sense ... it makes sense because they have stated it is about ensuring betas and rc's that might have issues can be shut down to force users to a known good version.
Could this be some secret test of the code and user willingness to tolerate such behavior? Perhaps. But until their actions tell me otherwise I'm inclined to believe their stated reasons and intent .
Sure the check only occurs during reboot but what is the alternative? An recurring check while the server is running that might take it down mid operation? That will ensure an even quicker shut down of a buggy release but I can't even imagine what the uproad about that would look like. Can you?
They "reserve the right" statement didn't even need to be said because of course they have that right, they just decided to make it clear that when they say they have no intention of doing it right now, they have the right to change their minds.
-
When is the phone home / kill switch going to finally be removed? The RC should be stable enough that it's no longer needed to protect data.
Asked and answered, it is removed when they issue a final release.
I also find it hard to believe it's needed to prevent piracy, I don't know if LT has any kind of real numbers on how many unlicensed servers are running but It seems to me like this kind of policy does nothing to prevent it anyway.
It isn't. That is what the registered USB is for. So ... a moot discussion
-
I'm just getting very concerned that something that was never a part of the unraid licensing or feature set has been added so quickly and with almost no official comment from LT, when the community is so vocal about our concerns.
It really worries me that a company that has always been so user focussed and still manages to add in kernel modules, etc. on request, has completely shutdown and not entered into the discussion.
All this is going to do is continue to wear away the trust that has been solidly built over the years.
Check your history. This was not quick and was not without official comment. LT is likely not commenting because they already have (and has been quoted in this thread) and it apparently was not enough; also it is clear some people will simply never agree with this precaution in a Betas or RCs and have convinced themselves it is a "feature" to be debated then they know darn well it is removed when final.
For those people the answer is simple: don't run Betas or RC's
For people who are worried this is a harbinger of inclusion into a Final Release the answer is simple: enjoy the ride on your slippery slope.
For people who are worried about what is transmitted the answer is simple: don't run Betas or RC ... or do some forum searching because I'm like 99% sure LT already mentioned that it is a license and version check. They don't need anything else, and have not done anything else in their history IMO, to make me think they are collecting any more info. Even their diagnostics snap shot intentionally tries to avoid pulling personal info.
Finally, if you don't trust them now at this point, why would you trust them to tell you if they are doing something Bad. You should verify and do some packet sniffing to prove to yourself what is or is not being sent over your network.
-
I don't like the idea of a killswitch like this at all. What happens if LT goes out of business tomorrow?
You do realize this only applies to Betas and RC's right? If they went out of business today you could roll back to the last Production release and go on your merry way.
Seriously, one guy has a problem, of his own making, by his own admission "I made a boo boo", and everyone grabs their pitch forks?!? This is not new, and if anyone thinks it is new then they clearly have not been reading the release notes. In fact this entire topic was hashed out already when it was first instituted. Don't like it? Don't run Beta/RC. Period. Don't have a dependable internet connection? Don't run Beta/RC. Used to have a dependable connection but are at risk of losing it? Revert to production and live a happy life. Don't want any info, whatever it is, being sent to LT on machine boot? Don't run Beta/RC.
In short, literally every single complaint lodged on the phone-home/kill-switch topic is solved by "Don't run Beta/RC".
-
Reasonable people can disagree.
-
re: the general discussion and not a specific person or issue but ...
This is why LT has considered using closed betas and probably does for really early stuff. Without the Kill Switch I imagine we'd be lucky to even get access to RC's no less Betas.
As for an RC not having the kill switch code because its supposed to be "release ready" ... um ... reasonable coding practice says that the code is easily commented out or the check disabled via a true/false toggle. Having it in RC code has hardly coding faux pas.
-
As someone who just did that ... hmmmm... is there a chance you didn't stop all torrents before you shut down the old docker? I can't be sure that is your problem but I have found sessions of most things don't like it if you don't close things out properly. In this case stop the torrents, then shut down the container, then copy session data, start the container, and start the torrents. Sort of how yuo have to stop the Plex server before you go copying the Library or it won't work; or used to not work at least.
Frankly I wish we had a more graceful shut down of the container because without stopping the torrents your tracker will not be notified of the stoppage and will register that you are seeding the same file twice until it ages out of their system. In a typical application shutdown like utorrent on windows at least exiting the application also first generates a torrent stop being sent to the tracker. We can't exit the application in the docker and docker shutdown just seems to kill it. Next thing I know my tracker is blocking me for too many seeds until they time out
But that is a tracker issue and not related to your problem exactly. -
Success on all counts. When I figure out how to successfully reduce the autowatch interval (as opposed to the schedule interval in the rc) I'll post back.
Thanks so much. Enjoy your movie!!!
-
OK very weird.
This rss feed has always worked as entered. I played around and removed the bookmark portion and it loaded, but of course with a butt load of torrents that I don't care about. I put back the bookmark bit and it failed again.
Of note is that right now I have no torrents to download because there is nothing new so my bookmarks list is empty.
Next I manually added a bookmark at the tracker site and BAM ruTorrent saved the feed and shows only that single bookmark as expected.
Soooo like I've said a few times now, this is my problem to deal with now not yours, but I'm adding this for any others that might have a similar problem.
In fact it is known: https://github.com/Novik/ruTorrent/issues/1068 it is also in theory fixed, but I wonder if a regression was introduced
-
You rock man. I was gonna suggest that last bit about the commented line too hahaha
So ... another rss feed loads fine. So many it is just the first tracker rejecting for some reason despite it loading in my browser and working on the old rutorrent ... coincidence I guess. but it is my problem to solve now, not yours.
Thanks so much!!!
But that is a tracker issue and not related to your problem exactly.
unRAID Server Release 6.2 Stable Release Available
in Announcements
Posted
upgraded. all dockers working as expected. Great work!