PM George with your user name. It may help, he can do tricks with your assignments if you really want to keep them.

I am in the same situation, I won't be at the buttons and all the mill will stop during the whole July (1st to 31st). But I am not going to take any action, what will expire will expire. All the LL we can't finish till July 1st, will be finished [U]anyhow[/U] AFTER we will be back, with or without assignment, they will count as DC if we lost the reservation and somebody else LL them before we are back. For the GPU72 work, Chris will kick us out by himself if he gets pissed off with us holding back the progress of the factoring front... :razz: but we never queue more than few hundred exponents, or 1-2 days of work, so in case we lose them and somebody do them in the meantime, then that will be "work in vain" when we come back (i.e. "error 40, no needed"). The effort of unreserving all, etc is too big, and stopping everything (i.e not requesting more work) before we go would also result in some lost (idle) time [U]before[/U] we go, so it does not worth, a day or two may be lost anyhow. As it is, we will close down everything few minutes before we go to the airport, and on August we will turn them back few minutes after we come back, and let P95, cudaLucas, and Misfit deal with the assignments...

[QUOTE=TObject;403782]Ubuntu has something called "RootSudoTimeout", which is 15 minutes by default.[/QUOTE]

That only applies to the sudo command, which temporarily applies root privileges (more accurately, temporarily switches users) to whichever command it's prepended in front of, and *only* that command.

To do any further work as root, you must continue prepending sudo to each and every command.

The slight difference is that if you have successfully entered your sudo password within the last "RootSudoTimeout", further invocations of sudo will not require you to retype the password. However each command is run with full root privileges regardless of that timeout, and the owner of a process cannot change from root to non-root.

So the hypothetical you suggested is unrelated to the timeout you found, and is indeed impossible.

To avoid needing to write sudo before each command, you may run what chalsall wrote -- that (permanently, or rather until changed by the user again) changes the user of the terminal to root (not just the user of any commands run to root).

[QUOTE=LaurV;403802]For the GPU72 work, Chris will kick us out by himself if he gets pissed off with us holding back the progress of the factoring front... :razz: but we never queue more than few hundred exponents, or 1-2 days of work, so in case we lose them and somebody do them in the meantime, then that will be "work in vain" when we come back (i.e. "error 40, no needed").[/QUOTE]

To put on the table, GPU72 no longer automatically unreserves overdue assignments (although the warnings still appear).

I will attempt to contact the assignees to ask of their intentions, and will instruct my systems to unreserve the assignments if no response is received, and/or if they are clearly "Newbies" who ran a few assignment, and then left.

Thanks for clarifying, that is perfect.
As most of my GPU72 assignments are DCTF in 52M to 71 bits, there is not so fat a chance that someone will be needing them done before August 2nd, or 3rd. All good here.

That's odd
 

As shown in the capture, I was a bit over 36% on the DC of 34698809. When P95 checked in this morning, PrimeNet responded, "error 43, Invalid assignment key."

It is not a terribly big deal, but I wonder how it came to pass. :huh:

owftheevil Manual testing 34698809 C 2015-08-25 11:28 1.4 44.8193 565bc8ee116618__

Manual test of that user started yesterday with a valid assignment - did your time run out or did you not have a real assignment for that one?

[QUOTE=kladner;408745]As shown in the capture, I was a bit over 36% on the DC of 34698809. When P95 checked in this morning, PrimeNet responded, "error 43, Invalid assignment key."

It is not a terribly big deal, but I wonder how it came to pass. :huh:[/QUOTE]

Looks like someone checked in the matching DC. When that happens, any assignments are expired since they're no longer needed:
[URL="http://www.mersenne.org/M34698809"]M34698809[/URL]

The result that came in today did have an assignment for it. Was your assignment the one that expired back in May of 2014 but you were still working on it anyway? I'm guessing not since that one hasn't checked in since March of 2014 and was only 0.1% done at that time. :smile:

[QUOTE=manfred4;408772]owftheevil Manual testing 34698809 C 2015-08-25 11:28 1.4 44.8193 565bc8ee116618__

Manual test of that user started yesterday with a valid assignment - did your time run out or did you not have a real assignment for that one?[/QUOTE]

I only get LL/DC assignments through Prime95. I usually have one of each unless an assignment is within four days of completion. A DC typically takes me 20-30 days. Also, there is no record of my assignment having expired. Again, it does not matter that much, but I did check in with it on Aug 23 without incident.

[QUOTE=kladner;408784]I only get LL/DC assignments through Prime95. I usually have one of each unless an assignment is within four days of completion. A DC typically takes me 20-30 days. Also, there is no record of my assignment having expired. Again, it does not matter that much, but I did check in with it on Aug 23 without incident.[/QUOTE]
Using the GPU72 proxy?
Very, very rarely I've had first time tests transformed into DCs without warning via innocent poaching. One of the "poachers" was Prime95 so I assume it was innocent [though you know what they say about assumptions...].

[QUOTE=sdbardwick;408788]Using the GPU72 proxy?[/QUOTE]
Yes, I am.
[QUOTE]Very, very rarely I've had first time tests transformed into DCs without warning via innocent poaching. One of the "poachers" was Prime95 so I assume it was innocent [though you know what they say about assumptions...].[/QUOTE]

I suspect no nefarious deeds. I am just puzzled. This was definitely a DC from the beginning: a 34M. Ah, well. Let it go. :smile:

I wouldn't let it go, this is a bug somewhere in someone's code, which means it could happen again (wasting more cpu time). We (by which I mean not me) should be looking into the root cause and possible fixes for it.