The files in which logs piled up were /var/log/syslog and /var/log/kern.log.
I suppose by disabling debugging the logging is off?

Thanks,
Jon

Yikes. Indeed just confirmed that (somewhat unexpectedly) all the EKOS messages go to syslog...
I don't know how one can get to several GB that way.
One thing to prevent it is activating the 'log to file' option of kstars, then all messages end up in $HOME/.local/share/kstars/logs. Will at least prevent your system clogging up.

What? how are they going to syslog?! let me check here.

EDIT: Just tried with all combinations and can't get a single message to syslog or kernel log. What messages are you seeing? Do they come from specific drivers?

It's all the stuff that is (also) written to the message consoles of kstars:
Attached is the output of 'journalctl -b -g kstars' on my machine (openSUSE Tumbleweed).
(IMHO you should also allow to attach simple gziped text files, not onlt archives )
When I activate 'write to file' the log to syslog stops.
Likely some journal setting, to include all sort of stdout/err stuff to the syslog? I'm not too familiar with configuring logging, but will try to have a look.

Well, it's not something in KStars itself. Maybe OpenSUSE logs everything that goes to stdout? If you "disable" logging, it also logs nevertheless?

I think it must be a feature of the DE/Window manager. If I start kstars from the command line, nothing gets logged to syslog. Only if I start via the start menu (KDE plasma). So it's somewhat similar to when started from systemd. There exists a setting for that in case of systemd services, like 'StandardOutput=null' (man systemd.exec), but I don't know where to put that directive for programs started from the DE....
There seems to be a way to do it from the application, like only logging to stdout when called from a tty.

This may help you until you find the problem. Rotate logs automatically linoxide.com/linux-how-to/setup-log-rotation-logrotate-ubuntu/

Plus learn to start Linux in safe mode linuxconfig.org/how-to-boot-ubuntu-18-04...ency-and-rescue-mode to "untrash" your system :-)

Thanks for the advice. By using the LiveCD I was able to recover one of my systems.

I am going to disable all the logs now as a temporary solution.

So I have an update.

Disk space became full again last night. I enabled logging on file though.

I am going to check what actually happened. But for now I think that this happens when the computer fails to download an image from my QHY165C, i.e. it is stuck in "capturing an exposure". This problem occurs rather frequently on Ubuntu 18.04 and macOS with INDI.

I should also mention that a similar problem with my camera exists on Windows (SGP), but instead of being stuck at exposure it is stuck while downloading the image.

Kind regards,
Jonathan

So which disk ran full? / or /home? (or are those on the same disk?)
Is it the kstars/ekos log file that is huge, or is it (hardware device) errors from the kernel?
You said you're going to disable logs. Did you? seems not...

So I analysed the logs and found what happened.

The following log entry was written simultaneously into /var/log/syslog and /var/log/kern.log at a rate of SEVERAL HUNDREDS THOUSANDS TIMES A SECOND PER FILE:
Usingreturned 211,661,935 matches in /var/log/syslog ALONE.

I think this is a major issue, but I understand that this might be an issue with the QHYSDK, not INDI.

I have filed a bug report on the INDI GitHub.

Many thanks,
Jonathan

Thanks, I just contacted QHY regarding this!