Iain Melville is friends with Hy Murveit


Your fix looks good so far. I rebuilt with the change you suggested and it seems to work with the dusk and dawn offsets cranked right up so I can see the scheduler waiting to start, then shutting down after a short period. Also seems to work when dusk (plus offset) has already past on starting the scheduler. I'll let it run through the night for a few days and report back.

This seems like a great area for unit tests - there must be some already (I would have thought). I must admit I have not looked.

Thanks for the rapid response on this Hy.

@Paul are you sure each entry in your scheduler has twilight ticked? You might know but to get the twilight config to apply you have to double click (each line in your schedule I think), make the change (tick twilight) then click the tick that appeared when you first double clicked the schedule line. Then remember to save your schedule once all done! Once you have forgotten to do it a few hundred times it becomes natural. There are threads on this but I couldn't find them when looking just now.




It’s late here now but I will give that alternative fix a try tomorrow or on the weekend and let you know how it goes.




I am running an AllSkyCam and have set up a very basic profile with just a camera (and a mount simulator) in order to capture a sequence of wide angle shots throughout every night.  In order to prevent daytime shots, I have set up a schedule that will repeat forever with twilight constraints and have tuned the offsets for dusk and dawn.  Previously I was hit with an issue that prevented kstars from running through the night (audio notifications causing file descriptor limits to be breached).  Now that is identified and eliminated, I have found the scheduler would not stop due to twilight constraints being passed at dawn.

In short I tracked down and changed this line of code in ekos/scheduler/scheduler.cpp: 

line 3718

if (currentJob->getEnforceTwilight() && ((Dawn < Dusk && preDawnDateTime < now) || (Dusk < Dawn)))

to the prior (simpler) version which was changed on 7th July 2021.
if (currentJob->getEnforceTwilight() && now > KStarsDateTime(preDawnDateTime))

The commit is detailed here .

This fixes the issue for me after some testing with large offsets to bring dawn closer - I'll post again if it does not work for me when running under normal operation.  I also added some logging showing the values of the variables involved in the prior check.  Does the function KStarsDateTime(preDawnDateTime) perform an important role in the logical check perhaps?  My log line was:
//    appendLogText(i18n("Dusk=%1, Dawn=%2, preDawnDateTime=%3, now=%4, KStarsDateTime(preDawnDateTime)=%5", //      Dusk.toString(), Dawn.toString(), preDawnDateTime.toString(), now.toString(), KStarsDateTime(preDawnDateTime).toString()));

So I did not inspect the variable preDawnDateTime directly - I'm not set up for C++ development.

Kind Regards


Just confirmed a full night's run without the issue.


Thanks and regards


Turn off all sound alerts in Settings -> Configure Notifications

You have to select each entry with the 'play' triangle image icon and untick the play sound box. Make sure you scroll down the list and get all of them.

This should fix the issue.


Hi Jasem

Indeed, this was the cause of the issue.  By de-configuring all the sound alerts I was able to eliminate the problem.

The number of file handles in use by the kstars process has dropped significantly as a result.  Previously I was seeing >100,000 file handles in use at the point where the issue occurred.  Now I see a steady 331 file handles throughout the capture.

There's a problem with the sound playing function where no audio device is attached which is leaking file descriptors/objects => memory - suggest a ticket for this?

Results of a successful test are attached!  I'm looking forward to not restarting kstars every morning now!

This is after a successful capture of >1000 images - prior to the test, the number was 331.

astroberry@astroberry:/universe/Pictures/AllSky/Zenith/Light $ lsof -p 17482 | wc -l
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
      Output information may be incomplete.

Many thanks and if you need any help recreating then I'm happy to provide it.


I thought I had it fixed!

I just now installed/re-installed a load of packages in order to build and run the ekosdebugger, which I have now done. 

See my post here  for what I did.

After launching kstars in ekosdebugger this time, I ran my 'test' again, and got up to 931 files before the crash (a record).

Could my installing dependency packages have stabilised my system?  Perhaps.

While the process was still up but non-responsive, I decided to do some investigating.  I ran:

lsof -p 17864 > ~/Documents/kstars_file_descriptors_on_crash.txt

17864 was the pid of kstars.

I'm attaching the output.  There were over 100,000 file descriptors in use at the time of the crash and most of them seem to be labelled as type=STREAM.  I wonder if it's something to do with trying to play an audio file on successful capture of an image and failing while leaving the FD open?



Iain Melville replied to the topic 'New Tool: Ekos Debugger' in the forum. 2 years ago

Hi Gabriel

I was looking for the answer to this too.  Apparently, the apt repository that hosts the prebuilt and downloadable ekosdebugger application is not available to non-stellarmate owners.  However it is quite easy to download the necessary dependencies and compile it yourself.

First you will need to clone the ekosdebugger sources from github.  Navigate to a suitable directory on your pi.  The home will do just fine since the next commands will create a directory for the ekosdebugger sources.

git clone https://github.com/knro/ekosdebugger.git

Now you should install the dependencies (I'm not sure if all of these are required - and credit to another poster for this info).
sudo apt-get install -y git cmake qt5-default libcfitsio-dev libgsl-dev wcslib-dev
sudo apt-get install -y libnova-dev libusb-1.0-0-dev zlib1g-dev  
sudo apt-get install -y build-essential cmake git libjpeg-dev libcurl4-gnutls-dev libtiff-dev libfftw3-dev
sudo apt-get install -y libeigen3-dev libindi-dev 
sudo apt-get install -y extra-cmake-modules libkf5plotting-dev libqt5svg5-dev libkf5xmlgui-dev libkf5kio-dev 
sudo apt-get install -y kinit-dev libkf5newstuff-dev kdoctools-dev libkf5notifications-dev qtdeclarative5-dev
sudo apt-get install -y libkf5crash-dev gettext libraw-dev libkf5notifyconfig-dev 
sudo apt-get install -y libqt5websockets5-dev xplanet xplanet-images qt5keychain-dev libsecret-1-dev
sudo apt-get install -y breeze-icon-theme libftdi1-dev libdc1394-dev libftdi-dev 
sudo apt-get install -y libgps-dev libraw-dev libgphoto2-dev libboost-dev libboost-regex-dev 
sudo apt-get install -y librtlsdr-dev liblimesuite-dev libavcodec-dev libavdevice-dev 
sudo apt-get install -y libftdi1-dev libdc1394-22-dev libeigen3-dev

Some of them are duplicated but that doesn't really matter.  It took a while to download and install all these but less than 30 minutes.

Now you can:
cd ekosdebugger
cmake .

And after this has completed you should have a new binary executable (an application) called ekosdebugger in the ekosdebugger directory.  Make sure you are running it from the astroberry (windowed) session and not from an xterm (ssh session) from another machine as it requires an X display to run.  If you try and run it from an ssh xterm (as I first did) you might see this:
astroberry@astroberry:~/ekosdebugger/ekosdebugger $ ./ekosdebugger
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.

When you run it from the astroberry window (from the Terminal application) you should see a window appear where you can choose which modules to run under debug sessions and then launch kstars from within the ekosdebugger window.  It took a while longer than normal to startup for me.

Please ask if you get stuck or if you think I made a mistake (entirely possible).



Glad to see you contributing James.  It does seem that large numbers of files cablead to this issue, however that’s still a valid use case in my eyes.  I found another AllSky camera user who had reported the same thing.

Right now I’m looking for an easy way to obtain the ekosdebugger package/application which should help us to diagnose the issue.

I have cloned the source from git but seems there are many dependencies to apt-get before I can build it locally.

If anyone has the repository info where I can apt-get it directly then that would be appreciated.

Many thanks