QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Perpetual Change (Apparent Hang on Verify)  XML
Forum Index » Problems and Bugs
Author Message
Steven M. Alper



Joined: 05-Mar-07 08:09
Messages: 55
Offline

Forgive the obscure YES reference.

Verifies are hanging up at the last moment, apparently. I've got one working on a 92 gig quanta. At 33 hours I clicked the X button (no choices appeared). The X button is now greyed out at 42:09:53.

3 processes are waiting. (At 47 hours it'll be 4 processes.)

This is the most recent. The previous one I was able to delay and after a restart it forgot about the delay.

The drive it's saving to is a 300 gig external, with 3 quanta using approx. 247 gigs, with approx 53 gigs remaining.

How can I help?

Best wishes,

--

Steven M. Alper
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Offline

Steven M. Alper wrote:Forgive the obscure YES reference.

I'll have to forgive you, because I don't know the reference.

Verifies are hanging up at the last moment, apparently. I've got one working on a 92 gig quanta. At 33 hours I clicked the X button (no choices appeared). The X button is now greyed out at 42:09:53.

Two questions:

Does it happen consistently?

What version are you running? I made a recent change that would that might affect this. The change would have appeared in 1.0.0(49).

3 processes are waiting. (At 47 hours it'll be 4 processes.)

If it's what I suspect, you're going to have to kill -9 the action process. Either use the Activity Monitor or use the 'kill -9 <pid>' command. (A regular 'kill <pid>' is the same as a cancel, which you've already done.) A 'ps -auxww | fgrep QRecall' command will give you a clue as to which process started first. That's the one you want to kill.

Since this is a verify, there's no possibility of damaging the archive. The other actions will take off as soon as the first one dies.

- QRecall Development -
[Email]
Steven M. Alper



Joined: 05-Mar-07 08:09
Messages: 55
Offline

James Bucanek wrote:
I'll have to forgive you, because I don't know the reference. :?


Ah, well, that will be remedied....


Two questions:

Does it happen consistently?

What version are you running? I made a recent change that would that might affect this. The change would have appeared in 1.0.0(49).


I was running (48). Here's the tail end of the previous verify on the same quanta that I had to cancel:



If it's what I suspect, you're going to have to kill -9 the action process. Either use the Activity Monitor or use the 'kill -9 <pid>' command. (A regular 'kill <pid>' is the same as a cancel, which you've already done.) A 'ps -auxww | fgrep QRecall' command will give you a clue as to which process started first. That's the one you want to kill.

Since this is a verify, there's no possibility of damaging the archive. The other actions will take off as soon as the first one dies.


Killt it, using Activity Monitor. I guessed right. But the other processes did not leave waiting state. I had to cancel the compact (of the quanta that could not complete the verify) since there were no other options, reschedule the capture that was next and cancel the merge that followed that (again, no other options available).

After the rescheduled capture began, I launched QRecall to check my version and was notified of b(50). In the interest of beta testing I allowed the update and install to occur while the capture was ongoing. I was going to ask if there were any ill affects I should anticipate, but the capture just finished successfully (after about 42 minutes).

Best,

--

Steven M. Alper
James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1548
Offline

Steven M. Alper wrote:
James Bucanek wrote:
I'll have to forgive you, because I don't know the reference. :?

Ah, well, that will be remedied....

And it was! Awesome. Thank you.

Killt it, using Activity Monitor. I guessed right. But the other processes did not leave waiting state. I had to cancel the compact (of the quanta that could not complete the verify) since there were no other options, reschedule the capture that was next and cancel the merge that followed that (again, no other options available).

You might have had to wait awhile. When an action's process simply disappears, it will take several minutes before the scheduler will realize that it's died and update the queue of waiting actions. But there's certainly no harm in what you did.

After the rescheduled capture began, I launched QRecall to check my version and was notified of b(50).

I hope you meant b(51).

In the interest of beta testing I allowed the update and install to occur while the capture was ongoing. I was going to ask if there were any ill affects I should anticipate, but the capture just finished successfully (after about 42 minutes).

It won't affect any running actions. The only potential complication that I'm aware of is if there were other actions waiting on the one that's running. After the upgrade and scheduler restart, the other actions can be left waiting indefinitely and would have to be manually canceled -- very much like the situation you just went through.

- QRecall Development -
[Email]
 
Forum Index » Problems and Bugs
Go to:   
Powered by JForum 2.1.8 © JForum Team