Add-on is shutting down #16
Comments
|
The file loadable_libraries.txt should be inside the container. You can start a shell inside the container with the Portainer AddOn.
Press on the fourth icon to start the shell inside the container. |
|
If I could get a hand on that file, I could see what library he is talking about, and maybe compile it in. |
|
I have the same problem when I upgrade. |
|
After a full reboot this issue was gone and then I had the same issue as in #15. Because of that I downgraded the add on with a backup. It's now running smoothly again. |
|
@Sholofly , the postgis message is not fatal. Can you confirm this? Or do you still have update issues? |
|
Same issue here or is the upgrade taking long? Data page checksums are disabled. |
|
Indeed, the system is being shutdown from outside, and could not complete it's upgrade. |
|
I have the same issue. The loadable-libraries.txt shows the following: pg_upgrade_dump shows: pg_upgrade_server_log shows: I have created a complete file copy of the add-on after the upgrade, so if you want more info, let me know. |
|
Hi @arjen-w, Do you have enough free disk space to perform the upgrade? ERROR: tried calling catalog_get when extension looks like na old error: timescale/timescaledb#1682 (comment) If so, could you please pass the file-copy of the addon so I can investigate. |
|
After investigating all your logs, I think I could identify 2 issues:
This is a timescale-bug (timescale/timescaledb#1682 (comment)) that sometimes seems triggered. Perhaps due to low disk-space during upgrade?
Errors like This first step is failing, and it looks like the upgrade to Timescale 2.6 fails because the database is actively being used (thus, the timescale addon is being loaded). To fix this, I'm building a new update that tries to block incoming connections during this process... For users that don't have a backup, and are stuck with the 'empty password' problem: no worries. All your data is still there. Please give a shout here and I will instruct how to retry the upgrade process using your original data. |
|
Thanks for following this up - if there's a gist with the procedure to retry the upgrade process with original data I'd be happy to give it a whirl. |
I defintely do have enough diskspace. |
|
@arjen-w a plan zipped copy fill do fine. All files and logfiles there! Thanks so much! |
|
you should be able to download it from here: https://1drv.ms/u/s!ArMQ8sywUxlQiuIRvO3bmWkLXxwFKQ PAssword is timescaledb |
|
Problem is still present in 2.0.1 `Performing Consistency ChecksChecking cluster versions ok
|
|
Also here on 2.0.1 it is not working --auth-local and --auth-host, the next time you run initdb.
|
|
Same issue here on v2 and v2.01 |
|
Got the same as above 2.0.1 still fails. |
|
Hey... wait! @deku-m, @arjen-w, @bartbakels and @mgiebels, Do you have your timescale-capable databases listed in the configuration-section?
In the add-on dump from @arjen-w (thanks again! really helpful!) I see this error in the loadable_libraries.txt:
But not in other databases.... |
|
@expaso both databases are timescale enabled and I have the same problems as mentioned above. |
|
@Simanias, could you post the error message from the loadable_libraries.txt file? It's located within the addon in the /data/postgres directory after the addon tried to upgrade. It will tell what database is flawed, and what add-on version he is trying to load. Or can you post a screenshot from pg_admin and view the extensions, like so:
|
|
Hi @arjen-w, I am really trying to wrap my head around this: In the archive you sent me, the dsmrreader database is not in the timescale-enabled list of the addon config:
And it is exactly this missing database that is complaining about the upgrade. What is your state of the addon now? Are you running 1.1.6 with this database enabled? Either way, I will try to see if I can just query this for the upgrade, instead of relying on this list. |
HI, Indeed at my side it was the timescale_enabled which was missing for dsmr. |
Same here! after adding it into the config lines, the upgrade went fine! Not sure how I missed that yesterday whilie I was checking that... |
|
Sweet! 🥳! I thought I was going nuts! 🤯 .. I have the code ready to not rely on this list, but instead query it out myself, just to be sure. As you can see, it's not a trivial upgrade within the add-on itself. That's why it took a while ;). Thank you all for your support! 🙏 |
|
It didn't work for me and I just started over so I lost old data unfortunately. |
|
I only keep getting the Postgis error. Apart from that everything works. |
This error is non-fatal. The addon tries to update this extension on all databases just to be sure. |
I can help you with this. I assume you did not press 'remove' on the addon? If not, your data is still there. |
I did press remove because I couldn't get it to work anymore. I installed HASS directly on my SSD |
|
If the SQL backup was created using pg_dump, you could just do a pg_restore on a freshly installer add-on. |
|
I have no idea actually this info is in there. (a part of the sql) -- Dumped from database version 12.4 SET statement_timeout = 0; I just wouldn't know how to do a restore and where because I can't access my computer via pgadmin |
|
I do have timescale enabled on my dsmrreader db but still get an error. i run on a supervised has on vmware esxi config: databases:
Workorder shutdown dsmr `You can change this by editing pg_hba.conf or using the option -A, or
|
You can just use pg_restore as far as I can see, from any linux machine with Posgres 14 tools available. See also: https://www.postgresql.org/docs/9.2/app-pgrestore.html |
|
After upgrading to 2.0, the addon wouldn't start. I restored a backup (1.6) but still no luck. Now i just upgraded to 2.1 but now i keep getting the same error I cannot check in pgadmin since it keeps asking me for a password but there is none. |
|
Sadly, 2.0.1 didn't fix this. Exactly the same error as before ("Checking for presence of required libraries fatal"). Due to time constraints I haven't been able to log in via root to examine the container, nor will the add-on remain up long enough for any pgadmin4 sanity checks. RPi4 with HA OS. |
|
I had problems upgrading to 2.0.0 (I wrote in #14) and restored from backup. Now, I just upgraded to 2.0.1 and it's working for me 👍 |
|
I restored a backup so i went back from 2.0 to 1.1.6 (so maybe i could upgrade to 2.0.1 in the next step) but even the backup is not really working So i don't think there's any point in upgrading to 2.0.1 if the 1.1.6 version isn't working EDIT: i took the gamble and upgraded the non-working version 1.1.6 and this is the result I thought the 2.0 version of this addon came with PostgreSQL 14 |
Have you checked that all timescale-enabled databases are listed in the 'timescale-enabled' section of the addon? |
Correct, this version comes with Postgres 14. But.. to upgrade from 12 to 14, there are a certain tricky steps involved, namely:
In your case, it looks like Postgres 12 was not correctly shut-down before trying the upgrade. database system was interrupted; last known up at 2022-03-31 13:32:18 UTC Can you try again when the addon was shutdown properly? |
|
Aha, thanks for that - somehow I missed that I needed to add my ltss db to the yaml config. Is it not possible to check for existing database timescaledb status programatically? I also noted the following; apologies if this is also something I've missed. 2022-04-11 23:24:00.944 UTC [496] STATEMENT: SELECT PostGIS_Extensions_Upgrade();
|
No luck. The upgrade breaks on starting PostgreSql 12. It seems the database won't start because of that "invalid primary checkpoint record". Would be a shame to lose this database. More than a year of Solar panel, energy consumption, ... data. And another database (,postgis, not timescale) for another project. |
|
Hi, this is related to #14 - which is marked as closed. However, I don't think that the problem is really solved. Over there, the recommended approach is to downgrade and then re-direct a copy of the data directory. If anyone has successfully done this, I would appreciate a step-by-step summary. |
|
@kennethhaspeel Are you on Discord? If so, PM me at Expaso #3263 and I can try to guide you through it.. @dschien Maybe.. the upgrade process is protected against an error as in: when the upgrade fails, it will restore the data directories to it's old positions..but.. if Postgres fails to start due above conditions, the upgrade process is aborted too early and will not recover by itself. I am currently creating a config option to reboot this upgrade process. Can you SSH into your homeassistant as in, port 2222 ? |
|
No more people to help out? Closing issue! Thank you guys! |
Hi can't start the addon anymore since upgrading to 2.0.0
How do iI access the loadable_libraries.txt?
The text was updated successfully, but these errors were encountered: