-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gsconnect filled my disk with logging #988
Comments
Thanks for reporting, but there's not enough information here for me to track this down. I'll have to wait for more information before I can fix this. |
What other information could I give if it happens again? I was rather alarmed by my barely-operable computer, so I may have panicked a little! |
There should be a stack trace somewhere that leads farther back than the main loop (line |
Ah, OK! I had another look, as I have kept just the start of the log where it went wrong, and I cannot find a longer traceback; just in some of the stanzas of the log there is one more line
|
Unfortunately that only confirms that it was an event being processed by the loop :/ It might have to wait until the problem reoccurs with a more descriptive backtrace. |
Thanks again. I don't know whether the absence of backtrace in itself tells you anything? |
Nope :) |
I realize it's not the central issue here and fixing the GSConnect issue that leads to this this is the priority, but I can't understand why Ubuntu still maintains a One of the advantages to the journal is that its size is capped -- this CAN'T happen with a journal. Not unless you also copy its contents to a flat file, as Ubuntu seem to be doing. (Journald also deduplicates the log output into message catalog references, so it uses its allotted gigs of space much more efficiently than a syslog file. But that's secondary, really.) |
Thanks for the suggestion, @ferdnyc: I tried removing rsyslog and found that indeed it can be removed from my Ubuntu 20.04 system (it's not "essential"), but it is still "important" (i.e. part of a standard minimal install), so I'm not keen to remove it for now. |
I got this too today. I thought it was already fixed but something made GSConnect fill syslog again. daemon.js:729. |
I also don't have a deeper stack trace to provide (not sure where to look), and I also see that you're not maintaining this project (thanks so much for bringing it this far!) so this is really just for any future maintainer(s), but my log gave this additional line:
After that it's the line @rrthomas reported above about |
Duplicate of #588 ? |
@darkdragon-001 looks like it, sorry for the dup! |
This issue still affects my computer with Ubuntu 20.04.03 LTS. I had to 'cat /dev/null > /var/log/syslog' and remove the extension. |
Going to close this as a duplicate of #588, which is the oldest version of this bug I see. This one has been around for years, so lets keep all the info in one place, in hopes we might find out why some folks hit this and others don't. Feel free to continue discussion and debugging there :) |
Describe the bug
My computer ran out of disk space. The problem turned out to be
/var/log/syslog
, which was 338GB, full of copies of:Steps To Reproduce:
I don't know how to reproduce this. I stopped the extension, killed the daemon process, and it did not happen again so far.
(Sorry, no relevant messages.)
System Details (please complete the following information):
GSConnect environment (if applicable):
Additional Notes:
The time stamp of the endless log messages is precisely when my phone connected to my home network for the first time today.
The text was updated successfully, but these errors were encountered: