Get rid of the "Stop Addons" feature.

[sabeechen]

The "Stop Addons" feature was originally introduced many years ago when it was found that the Maria DB addon would corrupt its database when backed up while running. It worked well to solve that specific problem. Since then the Home Assistant devs have done a great job fixing that and a handful of other addons that would have trouble getting backed up while running.

Since then the feature has stuck around, and a lot of people using this addon get the impression that they still need to stop some addons. These there are dependencies between addons, the HA addon ecosystem has gotten a lot more complicated and interdependent, and the "Stop Addons" feature is not handling it well. If it can't restart an addon after some number of attempts it gives up leaving that addon potentially disabled forever. I went to some difficult lengths to try to handle all the possible corner cases, but more keep popping up.

The feature as a whole is starting to feel a bit misguided, and I plan to remove it entirely, but I wanted to leave an issue open for a while to get feedback and see if anyone actually needs it for something I'm not seeing.

[XalaTheShepard]

I regret your choice to remove this add-on.
This is my main solution to create back-ups and store them in the cloud. I tried local back-ups, but prefer to have a backup in the cloud also...

[VictoriousCupid]

I regret your choice to remove this add-on.
This is my main solution to create back-ups and store them in the cloud. I tried local back-ups, but prefer to have a backup in the cloud also...

The add-on is not removed. A feature that is not needed anymore will be.

[XalaTheShepard]

Thanks for the clarification. It is a serious relief 😊

[diamant-x]

I need it.
I just attempted yesterday to backup my 6GB mariadb that is used for HA recorder, firefly3 and nginx and it failed. Now it is corrupted, won't boot, and need to gof back to my backup to do so...

Please keep this feature around.

[michaeltryl]

Stop addon feature should stay.
I have recently restored a backup where Maria dubikke had been stopped and marai db failed when home assistant was restored, so it is still a problem

[jkrasinger]

Correct me if i am wrong, but till today i am not able to backup "MariaDb Add On" and restore afterwards without destroying my database. I think this is normal, you can not make a physical backup of MariaDB/MySQL while the Database is running, you must stop it or make a logical backup (i.e. mysqldump).

For that i would request that this feature should stay as long as there is no functional way to backup and restore MariaDB Add on without destroying Database.

[antimix]

Hi, I am not sure if it is a real good idea.
Having the possibility to not start a plugin at HA startup, or even stop it, may be useful.
It may happen (and happened to me) that in order to identify a strange issue on HA startup I had to stop all the addons (e.g. disable the Addon automatic startup) , and then , restarting HA I did not get the issue. Then just re-enabling one by one the addons I was able to find what Addon was causing the issue.
Whithout the possibility to restart HA with Addons disabled, it would have forced me to unistall all the addons and then reinstall and reconfigure all of them. In this way I avoided lots of work.

[diamant-x]

Having the possibility to not start a plugin at HA startup, or even stop it, may be useful.

That has nothing to do with this addon feature. @antimix

[reclaimer5146]

FWIW, I only switched to this addon only because of the stop addon feature. Prior to switching I did a restore and the MariaDB was corrupt. I don't backup to Google Drive, just backup to a mounted SMB share, so the only feature I'm using this for is the Stop Addon feature.

[kdelios]

This feature solves a real huge issue: If MariaDB is up and running during a backup it gets corrupted. Therefore upon a restore you loose the history. The MariaDB starts to fail, you must remove it and setup the built-in db, and then install back MariaDB.
I prefer to keep this feature.
PS. I never had MariaDB addon not starting after a backup.

[convicte]

@reclaimer5146, @kdelios do you know this for a fact, from the last year to year and a half personal experience, or is this a 'read in a thread' or historical knowledge?

MariaDB add-on introduced table locking and unlocking for backups, which at least for me works just fine - see screenshot below for multiple days of table stops/starts:

I must admit my experience is not extensive with n=1 backup restored without issues, but I wonder if it's a tempest in a teapot, if the above works for other people as well.

In all honesty, the add-on stopping function was much more of a nuisance for me. It would happen more than once that the add-on would not go back up after being stopped, because of some interoperability issues, as discussed by the maintainer.

[reclaimer5146]

@reclaimer5146, @kdelios do you know this for a fact, from the last year to year and a half personal experience, or is this a 'read in a thread' or historical knowledge?

MariaDB add-on introduced table locking and unlocking for backups, which at least for me works just fine - see screenshot below for multiple days of table stops/starts: I must admit my experience is not extensive with n=1 backup restored without issues, but I wonder if it's a tempest in a teapot, if the above works for other people as well.

In all honesty, the add-on stopping function was much more of a nuisance for me. It would happen more than once that the add-on would not go back up after being stopped, because of some interoperability issues, as discussed by the maintainer.

Mine happened probably about a year ago. Did a backup and restore to another VM, and the DB was corrupt. However, after using this addon, I tested restoring again to another VM, and it was fine. Have tested it a few times in fact. Could have been a one off issue, but all my research pointed me at MariaDB not being stopped. If HomeAssistant has since corrected the issue, then that's great.

[convicte]

Respectfully, what you describe is simple correlation and not causation, so unfortunately we cannot draw any conclusions on whether it would work now or not.

The fact it was corrupted once for you, and this maybe have been before the MariaDB change was introduced (not to mention what the cause of the corruption was in the first place), doesn't tell us much. Unfortunately, nor does the fact, that when you stop the add-on and back it up things worked. In that situation, the table-lock is not utilized on a running add-on, and hence you know nothing about its effectiveness or lack there of. The table gets locked before the add-on stops, so there is that.

So the only thing that we know is that MariaDB, when stopped, doesn't get corrupted when backed up.
The question remains, does it need to be stopped in light of the fact the table-lock exists?

[jkrasinger]

@convicte Your assumptions about a db-dump and a working restore afterwards are only correct partially, it depends on the Database Engine.
With an MyIsam Engine all will be fine and after copying (or restoring) the files the new Database will be OK. But with an InnoDB Engine (and HA uses an InnoDB engine) this is mostly not correct, even with an database/table-lock. In this case it may work, but mostly will not.
InnoDB Databases can only be safely backed up or copied with the official MySql tool (mysqlbackup) or with the MySqlserver stopped.

[convicte]

@jkrasinger, please allow me to clarify.
What you are saying is that my comments specific to MariaDB and in reply to MariaDB not being backed up correctly are not going to work in a completely different database engine, that I didn't indicate it would?

Sorry if this sounds snarky, but obviously I cannot know someone has another completely unrelated add-on issues, I've never dealt with, that this feature would be great for. I've only commented on the fact there is no information to prove MariaDB would need it, in light of the changes introduced. So unless this is confirmed to be wrong, my statement stands.

[kdelios]

@reclaimer5146, @kdelios do you know this for a fact, from the last year to year and a half personal experience, or is this a 'read in a thread' or historical knowledge?

MariaDB add-on introduced table locking and unlocking for backups, which at least for me works just fine - see screenshot below for multiple days of table stops/starts: I must admit my experience is not extensive with n=1 backup restored without issues, but I wonder if it's a tempest in a teapot, if the above works for other people as well.

In all honesty, the add-on stopping function was much more of a nuisance for me. It would happen more than once that the add-on would not go back up after being stopped, because of some interoperability issues, as discussed by the maintainer.

For sure it happened more than once, but long ago, and since I stop MariaDB.
But I will test a restore from a backup without stopping it at my test setup and will report back.

[convicte]

For sure it happened more than once, but long ago, and since I stop MariaDB. But I will test a restore from a backup without stopping it at my test setup and will report back.

Just please make sure the MariaDB logs show the table was locked during the backup, as indicated above.
This happens automagically when the backup is triggered, so it should have.

Thanks!!

[jkrasinger]

@convicte : Sorry, but it sounds to my ears as if there is a big misunderstanding. I'm talking about MariaDB(MySQL) and nothing else, but MariaDB has two different database engines integrated, MyIsam and InnoDB. These can be selected at table level. So when I talk about InnoDB or MyIsam, it's still MariaDB (or MySql).

TABLE_NAME 	ENGINE 	
event_data 	        InnoDB
event_types 	        InnoDB
events 	                InnoDB
recorder_runs 	InnoDB
schema_changes 	InnoDB
state_attributes 	InnoDB
states 	                InnoDB
states_meta 	        InnoDB
statistics 	        InnoDB
statistics_meta 	InnoDB
statistics_runs 	InnoDB
statistics_short_term 	InnoDB

[bcmitri]

I'm not sure if it's still an issue, but my main purpose for using the "Stop Addons" feature was to limit the overall memory utilization during backups. Prior to enabling that feature, my memory utilization would spike and cause my swap usage to go up. Since I do daily backups, this had a cumulative effect over time.

[kdelios]

I can confirm that MariaDB database was not corrupted and restored successfully at my test setup (RPi4 8G booting from SSD) without stopping it upon backup.

[michaeltryl]

And i can confirm that it did not work when i restored my home assistant on a rpi4 with ssd without a stop of mariadb

[sabeechen]

It sounds like there are still some legitimate use cases for stopping addons during backup. My main reason for wanting to get rid of it is that its almost impossible to keep the feature in sync with changes to Home Assistant's Supervisor, so its pretty likely to break things going forward until someone else notices and notifies me, and even then its very time consuming to figure out what went wrong. I'm going to keep it around and:

• Add lots of warning language around it in the settings about potential instability.
• Just do my best to keep it working and in sync with how addon starting/stopping works in HA.

[baflo]

It was introduced long ago before Home Assistant had a built in way to let addons know they're in the middle of a backup. Now that it does, all addons the developer is aware of handle being backed up live correctly.

@sabeechen This message implies there's something the addon should do to properly allow backups. I am using a community postgres addon where I don't see any special means to allow for backups. Also I cannot find any documentation on this in the addon development docs. Can you give me a hint?

[sabeechen]

@baflo The docs don't make it super clear, but in this section the backup_pre, backup_post, and backup_exclude options let you make the addon react to the start/stop of a backup operation. For example, here is the config.yaml for the MariaDB addon, whch makes use of it.

This is something the developer of an addon should implement, not their end users.

[baflo]

Thank you. I actually missed that :)

[LeChuck2909]

i noticed some addons not working properly after restore around the voice assistant like piper, whisper and openwakeword. if stopping the addon would help here, it would be a pro for keeping this feature.

[dm94]

I use add-ons that can be very heavy for the raspberry and I only turn them on at very specific times, so having this functionality is very useful to reduce consumption when I haven't manually stopped those add-ons

[quettih]

as many others said, a mariadb backup can't be restored if it was taken "hot" with open files. for this reason it is a good idea to keep "stop addon" still working!
as a workaround, you should invoke proper sql command to create a backup, but this is tricky on maria db. at the end, stop-backup-restart is the only really working, and less space consuming, possible solution.

[ThomasKlesse]

I need it - it is importend for me!
It is actually the only working way to backup without corrupted files.