Forum / NoMachine for Mac / Disk space taken up with old logfiles
Tagged: logfile
- This topic has 8 replies, 3 voices, and was last updated 5 years, 2 months ago by MickM.
-
AuthorPosts
-
September 10, 2019 at 12:28 #23573heywoodParticipant
Cleaning out an old El Capitan (10.11.6) machine. Updated it to latest NX (6.7.6); prior to that update, it had been running 6.3.6. I use NX to administer it remotely, but lately it has become sluggish to the point of being unusable.
I found a massive problem with cruft in /Library/Application Support/NoMachine/var/log/node/ . There are so many (small) logfile directories in that directory that even the most basic BSD/Unix/Linux commandline commands fail (even stuff like ‘ls’!).
I found mention of similar issues TR11K04084, TR12O08309, and https://forums.nomachine.com/topic/corefiles-fill-usrnxvardbfailed-dir. The last of those three includes responses from someone who sounds like they work for NoMachine, claiming this issue was fixed ~5 years ago.
Is it safe to just forcibly remove node/? I managed to calculate (using find, xargs, wc, etc.) that it has >20GB of crufty logfiles in it.
Thanks in advance for any guidance!
Gratefully,
-H
September 10, 2019 at 15:09 #23580heywoodParticipantEDIT: The NoMachine hidden directory inside the (sole) user’s home directory, ~/.nx/ , exhibits a similar problem. Even trying to count the number of files/directories inside that directory, for example by running “ls | wc -l” from the command line, runs for five minutes (that’s not a typo) with the hard drive audibly thrashing before producing any output. Eventually it returns a count of >260000 (one-quarter million lines), the vast majority of which are logfile directories of the form T-C-*, F-C-*, and so on.
I’m currently running a full backup (using Carbon Copy Cloner), manually excluding the directories mentioned above. Once that completes, I intend to do an erase-and-restore using a file-level copy; hopefully that will address the severe free-space fragmentation issues that have resulted from the runaway logfiles. Unfortunately, I neglected to exclude /Library/Application Support/NoMachine/var/log/node/ on my first backup attempt (I did remember ~/.nx/)—resulting in CCC taking ~16 hours just to build its list of files to compare and back up. (Even though this is an old machine—2GHz Core2Duo, 6GB RAM—my sense is that it should be much faster than that.)
I’ll continue with my cleanup plan for now, but I would be grateful for any pointers on how to avoid this “runaway logfile” situation in the future.
In particular, I’m aware of at least https://www.nomachine.com/TR12O08309, https://www.nomachine.com/AR12K00765″> and https://forums.nomachine.com/topic/nomachine-linux-workstation-6-1-6-generates-logfiles – but all of those refer to node.cfg and server.cfg at locations that do not seem to exist on a standard NoMachine installation on MacOS. Moreover, the only instances of those two files I see on this machine, at /etc/NX/server/localhost/ , do not have anything resembling the keys (SessionLogClean, SessionLogLevel, etc.) described in those articles.
Thanks in advance for any tips,
-H
September 10, 2019 at 17:06 #23584GegaParticipantHello heywood,
Several things needs to be done in order to resolve these issues.
1) To safely clean up ‘/Library/Application Support/NoMachine/var/log/node/’ and user’s .nx directories please run:
nxserver --shutdown
rm -rf log/node
rm -rf /.nx/T-* /.nx/F-* /.nx/R-* /.nx/M-*
nxserver --startup
Please note that by doing this you won’t be clean up whole .nx directory, since some of the files there might be important.
2) Configuration files are located in: /Applications/NoMachine.app/Contents/Frameworks/etc. Please set SessionLogClean 1 in node.cfg if it’s not 1 already.
3)These values look weird, so after clean up is done please monitor /Library/Application Support/NoMachine/var/log/node/, if the number of folders is increasing abnormally than it looks like a problem and we’d need logs to find out what goes wrong, here’s an article how to gather logs for in case it’s needed: https://www.nomachine.com/DT10O00163
September 11, 2019 at 14:05 #23590heywoodParticipantHello Gega,
Thank you very much for the detailed tips. I’d already been working on cleaning out ~/.nx/ (without removing cache/, config/, and temp/) and …/var/log/node/ (which I wasn’t sure if I could simply delete — thanks for clarifying!).
I’ll set SessionLogClean 1 as you suggest and keep an eye on …/node/ to see if I start getting the cruft buildup again. If that happens, I’ll gather full logs and submit them described at the link you kindly provided.
One related question: during my cleanup, I found copies of server.cfg and node.cfg in two locations: the aforementioned /Applications/NoMachine.app/Contents/Frameworks/etc/ (with user:group = nx:nx) and, separately, /etc/NX/server/localhost/ (with user:group = root:wheel). Timestamps in both locations are recent (past few days). Is it possible that this machine has an old/incorrect NX installation that is competing with the “proper” one? If so, what’s the best way to check (and fix) this?
Thanks again for your help,
-H
September 12, 2019 at 12:07 #23598GegaParticipantFiles in /etc/NX/server/localhost/ are different, these are part of regular nomachine installation so there’s nothing to worry about.
September 12, 2019 at 12:38 #23601heywoodParticipantIn that case, I’m confused: what is the difference (in function/purpose) between the two instances of node.cfg? (And the same question applies to server.cfg.)
In any case, I’ll keep an eye on logfile buildup in both places and post here if it starts accumulating in either one.
Thanks,
-H
September 13, 2019 at 08:18 #23608GegaParticipantFiles in /etc/NX/server/localhost/ are used internally and aren’t meant to be modified by user. It’s mainly used to indicate nx installation directory.
September 16, 2019 at 07:30 #23625heywoodParticipantPerfect—thanks for clarifying!
Cheers,
-H
October 18, 2019 at 07:50 #24059MickMParticipantSo just looking for clarification – did all this house cleaning solve your sluggishness issue?
-
AuthorPosts
This topic was marked as solved, you can't post.