docker cutils recent release not updating

[HansR]

btw: this is what my utils/bin directory looks like:
(just copy the runtimes from the distribution into that utils/bin directory)

Schermafbeelding 2024-09-18 162033.png

[Nossie]

yeah just wanted to check - I have the same files in the same place

and no - no joy


the docker container just acts like a minimalist linux install - and the full utils folder is mapped so it should be able to find the runtimes without issue.

I need to research more how this interacts with docker but from a big overview I don't think it really should.

[HansR]

and no - no joy

Any joy yet?

[Nossie]

haha morning - I was just zipping up a new log file when I saw this message - no joy.

So I've left it for a bit, you can see when the last update happened - I checked extra sensors and that had updated 12/09 - so I ran my run once script which goes through all the modules with a 5 second wait and the logs are below .... the diary error is back weirdest thing! extra sensors is now back up to date but I'm still no closer to narrowing down the error.

Other than the footer Hans, what else can you see is not updating?

[HansR]

haha morning - I was just zipping up a new log file when I saw this message - no joy.

So I've left it for a bit, you can see when the last update happened - I checked extra sensors and that had updated 12/09 - so I ran my run once script which goes through all the modules with a 5 second wait and the logs are below .... the diary error is back weirdest thing! extra sensors is now back up to date but I'm still no closer to narrowing down the error.

Other than the footer Hans, what else can you see is not updating?

The footer does not update because the SQLite error is still there and the index.html generation breaks off on that error. The only reason the modules update is because you run those separately (see your first logfile) which should not be necessary in normal circumstances.

I wonder: CMX also has a runtimes directory in its bin. How come that those have no problem and the CUtils SQLite does?
Do you mixup something here? Note the CMX runtimes are different from the CUtils runtimes.

[Nossie]

I wonder: CMX also has a runtimes directory in its bin. How come that those have no problem and the CUtils SQLite does?
Do you mixup something here? Note the CMX runtimes are different from the CUtils runtimes.

No - the runtimes are in the utils folder as you showed the image

[Nossie]

Is there any runtime log or something that shows which architecture it selects?

I'm rebuilding the container to ubuntu to 24.04 LTS (Noble Numbat)

I'm trying that first before I consider changing to debian, not that it should be an issue.

[HansR]

I have no idea about a runtimes log.
Maybe anybody else?

[Nossie]

updated to the latest version of ubuntu - seemed to take longer to run my run once script but nothing different - ran out of time for now


weird

[Nossie]

Hi Hans,

I'm still no closer sadly - the only error I have to go on is still the diary.db - are you able to do me a favour?

Can you add a setting in utils to allow me to set the location of diary.db? I'd like to try this

Code: Select all

Data Source=/opt/CumulusMX/data/diary.db;Mode=ReadWriteCreate;

I've tried changing it in the environment but it seems to be ignored - the weird thing is it's all fully accessible within the container

Code: Select all

root@7c56e66757a2:/opt/CumulusMX# sqlite3 /opt/CumulusMX/data/diary.db
SQLite version 3.45.1 2024-01-30 16:01:20
Enter ".help" for usage hints.
sqlite> .schema
CREATE TABLE IF NOT EXISTS "DiaryData"(
"Timestamp" datetime primary key not null ,
"entry" varchar ,
"snowFalling" integer ,
"snowLying" integer ,
"snowDepth" float );
sqlite> 

[HansR]

OK, I'll make something. But in the meantime I have the following remarks:

1. The diary is currently openend as: DataSource=data/diary.db; Mode=ReadOnly;
2. I will make a parameter for the DataSource without the Mode so it will remain readonly!
3. I will also make a parameter for the Mode.
4. Defaults will be the current values. The user will be responsible for the values, when issues just delete the parameters and the defaults will return with the next generation of the diary module.
5. Note that according to the docs the DataSource "Gets the path to the database file. Will be absolute for open connections." so in the meantime you may wonder if the diary is open somewhere (CMX? some db-browser?) if I understand things well.

This should give you full control. When empty the defaults will be what they are now.
I'll post the test release here.

[Nossie]

if all you are doing is reading existing values and generating from cmx then write may not even be required?

I was just using it my testing

[HansR]

@nossie:
Here is a special 'Nossie'-release. When run (with whatever argument but 'diary' is advised) it creates two parameters as discussed above at the end of the cumulusutils.ini. You may alter those parameters as you wish and then run CUtils again with the parameter diary.

Let me know how you get on (with logs please)

[HansR]

I checked the zip, the timestamps are OK, you have the correct executable.
You should see something like:

Code: Select all

2024-10-03 21:49:52.011 Information CumulusUtils : Read dayfile.txt succesfully - 1941 records
2024-10-03 21:49:52.030 Information CumulusUtils : RecordsBeganDate used: 01-01-2020 00:00:00, Number of days removed from list: 204
2024-10-03 21:49:52.032 Information Diary constructor: starting
2024-10-03 21:49:52.045 Information Generating Diary connectionstring - DataSource=data/diary.db; Mode=ReadOnly;
2024-10-03 21:49:52.310 Information Diary constructor: stop
2024-10-03 21:49:52.311 Generating Diary - Starting
2024-10-03 21:49:52.312 Information End Generating Diary

It is in the constructor you see the connection string. If you see that you should see the parameters in the inifile. If you do not see those than something is seriously wrong between the executables and related files. I am sorry, but I cannot help you further on your local situation. You have the adjusted executable and it runs on my machine (note that if you run website you should see in the footer: Version 7.2.0 beta 2 Nossie Only and Diary in the Reports menu as in my site).

But apparently you are not running this new executable but still the old one. A caching issue?
I don't get it.

[Nossie]

But apparently you are not running this new executable but still the old one. A caching issue?

sorry that was the only reasoned I pm'd you - and you answered my issue - thanks.