'No space left on device' glitch causing log failure
Hi all, these are the last entries in my log, but my bridge is still listed on Atlas and client functionality is fine. Latest stable version on OSX10.4. Needless to say, the disk is not full and 'tor' can write to that directory just fine now. Oct 05 22:52:09.000 [warn] Couldn't open "/Users/tor/tor/state.tmp" (/Users/tor/tor/state) for writing: No space left on device Oct 05 22:52:09.000 [warn] Unable to write state to file "/Users/tor/tor/state"; will try again later Oct 05 23:10:27.000 [warn] Couldn't open "/Users/tor/tor/cached-consensus.tmp" (/Users/tor/tor/cached-consensus) for writing: No space left on device Oct 05 23:11:32.000 [warn] Error writing to "/Users/tor/tor/cached-descriptors.new": No space left on device Oct 05 23:11:32.000 [warn] Unable to store router descriptor {more of the same until Oct 05 23:11:34.000} GD -- http://www.fastmail.com - Access all of your messages and folders wherever you are
Is it possible you have a disk or user quota setup? On October 10, 2016 9:15:46 AM CDT, Geoff Down <geoffdown@fastmail.net> wrote:
Hi all, these are the last entries in my log, but my bridge is still listed on Atlas and client functionality is fine. Latest stable version on OSX10.4. Needless to say, the disk is not full and 'tor' can write to that directory just fine now.
Oct 05 22:52:09.000 [warn] Couldn't open "/Users/tor/tor/state.tmp" (/Users/tor/tor/state) for writing: No space left on device Oct 05 22:52:09.000 [warn] Unable to write state to file "/Users/tor/tor/state"; will try again later Oct 05 23:10:27.000 [warn] Couldn't open "/Users/tor/tor/cached-consensus.tmp" (/Users/tor/tor/cached-consensus) for writing: No space left on device Oct 05 23:11:32.000 [warn] Error writing to "/Users/tor/tor/cached-descriptors.new": No space left on device Oct 05 23:11:32.000 [warn] Unable to store router descriptor {more of the same until Oct 05 23:11:34.000}
GD
-- http://www.fastmail.com - Access all of your messages and folders wherever you are
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Jason Jung 7942 B145 5E45 1D53 37C8 1204 8DA4 A1DB CBE6 35AE
On Mon, 10 Oct 2016 15:15:46 +0000, Geoff Down wrote: ...
Needless to say, the disk is not full and 'tor' can write to that directory just fine now.
Question is whether it was full (or out of quota) at the time of these messages. MacOS has/had a habit of throwing a few GB on the disk and then removing them again. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
On Mon, Oct 10, 2016, at 04:28 PM, Andreas Krey wrote:
On Mon, 10 Oct 2016 15:15:46 +0000, Geoff Down wrote: ...
Needless to say, the disk is not full and 'tor' can write to that directory just fine now.
Question is whether it was full (or out of quota) at the time of these messages. MacOS has/had a habit of throwing a few GB on the disk and then removing them again.
Andreas
It would have to have been several tens of GB - nothing else running at the time threw an error either. I'll try a HUP as suggested. -- http://www.fastmail.com - Send your email first class
On Mon, Oct 10, 2016 at 03:15:46PM +0100, Geoff Down wrote:
Hi all, these are the last entries in my log, but my bridge is still listed on Atlas and client functionality is fine. Latest stable version on OSX10.4. Needless to say, the disk is not full and 'tor' can write to that directory just fine now.
Yes, once Tor has failed to write to its log file, that file descriptor is essentially broken until you instruct Tor to try again. If you send Tor a HUP signal, it will reset a bunch of things, including its logs. I would assume that it really did run out of space, if only for that moment. That said, OSX10.4 is Tiger, right? The one that became unsupported over seven years ago? (But let's not make this thread about whether it's morally appropriate to run obsolete OSes -- except to acknowledge that maybe it has bugs in it.) --Roger
participants (4)
-
Andreas Krey -
Geoff Down -
Jason Jung -
Roger Dingledine