When upgrading cacti while the MySQL partition is full, misleading errors are shown during the upgrade.
Describe the bug
We were upgrading on our test host from 1.2.14 to 1.2.16 and did not recognize that a previous import of a DB had filled up the database partition.
Due to this SQL related problem, the installer noted in the prerequisites list: "path_php_binary is not updated . Please update in settings table" We checked the path but found no issues with it, so we were confused at that point. There was another error listed, telling us that the cacti user would not have access to the timezone table. THis was also confusing because it had worked perfectly. But it got us to try and re-import the TZ-data, which then failed and gave us the idea to check the disk space.
The errors noted in the prerequisites list were a bit misleading (even if we should have detected the full partition way before the upgrade) and users can be confused about these messages, when the actual cause is something completely unrelated. So maybe it is a good idea to add some sanity checking to the updater-code, which prevents such behavior. Not sure if there is a simple way to issue a SQL command to check if the DB partition might be full.
One approach could be to use: SHOW VARIABLES LIKE 'datadir' and then do a "df" on that folder.
To Reproduce
Fill up the partition that contains your SQL data Start the upgrade process Observe the errors shown in the prerequisites list
Expected behavior
The upgrader should note that MySQL has a generic problem instead of reporting things that are actually not broken in fact.
I am mixed on this one. While we could add something to the installer, you really should have monitoring alerting you to the fact that it was filling up well before it got to that point. When the MySQL partition fills up, things tend to break in very bad ways. PHP does have a function to pull the free space and total space, but it seems like doing extra work for something a systems admin shouldn't let happen to begin with.
I would agree with @cigamit that disk space isn't really something we would cover because the MySQL partition could be on a different one to Cacti and even on a different server.
thanks for your comments and I totally understand the mixed feelings :)
At least the bug is filed here under a clean enough headline, so i believe that users are able to find it and get the idea to check for this specific situation, as i experienced myself in lots of problems that i encountered in the past. It's usually the little hints that you get from here and there, which make you wake up and check for things. ;)
Just some thoughts on that, from my past years of experience: Generally applications are getting more and more complex everywhere and you need lots of knowledge, it would help the operators, when the application gives more hints about failures. Happens more and more that single admins replace a whole data center ops team ... and Cacti itself is already a rather complex application which sometimes involves quite a lot of knowledge and experience when debugging.
In the end it's your decision though, i can also understand that it is adding overhead on your side, checking for every single little mishap. Maybe a line in the update documentation would be good, so that the user knows what to check before attempting an update.
Cheers & please keep up the good work!
All I can see practical is some internal checks once a day that warn the cacti admin that this or that is above x percent utilized. It could be done in thold, but it would maybe more standard right in cacti.
You really can not block someone from copying a bunch of files and forcing the upgrade though. There is not switch to correct a PEBKAC. But we can warn someone.
Many applications nowadays have some kind of internal resource monitoring, maybe this falls in the same category. Not top of the list, but it would really be a nice add-on, if it came right out of the box. And yeah, PEBKAC can happen to anyone :)
@bernisys, happens to me all the time. I'm going to mark this as a post 1.2.17 enhancement.