Checking for tables to rename...

[musat]

Hello,

Our JSS ran out of space over the weekend. I've cleared some old log files and rebooted. Now the JSS is stuck at " Checking for tables to rename..." I figured before opening a support ticket, I'd check here to see if there was something quick to try.

[rtrouton · Accepted solution]

@musat][/url,

I'd recommend opening a support ticket. That said, I ran into a similar-sounding issue last week and have a post on what I did to resolve my issue:

http://derflounder.wordpress.com/2014/02/01/fixing-caspers-mysql-database-with-mysqlcheck/

[corbinmharris]

I had the same issue last week when the Mac server crashed. Basically followed the instructions that are provided above -n http://derflounder.wordpress.com/2014/02/01/fixing-caspers-mysql-database-with-mysqlcheck/

[musat]

Thanks for the link. It required patience, but the server finished the check after ~4 1/2 hours. Optimize did take less than one minute. After a reboot, everything is back up and running. Now to do a few checks to see what fallout there is from this outage. And add some space to the server so it doesn't happen again.

[rhysforrester]

Similar situation, my jss (currently) sits on a Windows VM and a cluster of them went down last night. I'm back up and running (thank you!) so now all I need to do is manage a chunk that seem to have become unmanaged during this outage. Cheers @rtrouton

[jmahlman]

@rtrouton

Thanks, fixed my JSS with this!

[rrouleau]

FWIW - This post saved me big time today! Thanks @rtrouton!

[damienbarrett]

Ditto, Rich. This post saved me this morning! Thanks for your hard work and support of our Mac IT community.

[stevehahn]

+1 Thanks @rtrouton! You saved my bacon yesterday.

[rickwhois]

Is there any way to increase the buffer for the mysqlcheck process?

I'm following along with the mysql repair procedure as described by @rtrouton but it has been taking a dogs age to complete. i let it run for about 14 hours and it was hung up half way on fonts. I am able to restore to the previous days backup for now but would eventually like to repair and optimize the tables so this doesn't occur again. cheers!

[rickwhois]

i let the repair run overnight. it literally took over 16 hours to complete. I rebooted and still get this dreaded Checking for tables to rename....

Below is what got returned after the repair was finished:

repairing tables
jamfsoftware.fonts
error myisam_sort_buffer_size is tool small
warning Number of rows changed from 0 to 10703257
status ok

I found this thread https://jamfnation.jamfsoftware.com/discussion.html?id=53
after looking at my /etc/mysql/my.cnf
i noticed my settings for these were:
key_buffer = 16M
max_allowed_packet = 16M

I've changed them to 128M.

I'm at a loss here. Does anyone have any other suggestions?

[rickwhois]

I have resolved my issue. Just in case anyone finds this thread and runs into my issue, I'll put what my issue was and how it was resolved.

Issue: during JSS startup it hangs and displays Checking for tables to rename....

Resolution: I ran database repair as described above. it did not fix it, but it did shed light on the row in my database that was causing the issue. FONTS! somehow we selected to collect inventory of clients fonts. The row in the sql db was over 6GB! I disabled the collection option and then proceeded to remove the font from mysql. from the mysql command line enter " delete from fonts; " to dump the fonts database.

I suppose you could do the same for any other row that gets too big and you no longer need to collect.

[turnere]

FYI, I had this problem today when my server ran out of space... JSS was stuck at " Checking for tables to rename..."

I went into the JSS Database Utility, saved a backup of the JSS database, at which time it repaired all sorts of tables, etc. Backup completed in less than 8 minutes, restarted Tomcat, JSS came back alive and things are all good now.

[chilcote]

+1 for Rich's blog. Saved my bacon, again. That's a lot of bacon that Rich has saved. He's like the global leader in bacon saving.

[stphnlee]

Following the steps here resolved this for me: http://derflounder.wordpress.com/2014/02/01/fixing-caspers-mysql-database-with-mysqlcheck/

[flopez]

Thanks turnere! This worked for me.

[csanback]

+1 for turnere too

[joebesser]

We ran into this and the posts here were a big help. A note: as the database repairs, it seems to create a copy of each table, which in our case was filling up the volume and causing the repair to fail. Make sure your freespace is enough to handle a full copy of your largest table.

[howie_isaacks]

This morning, I had to just restore the database from the last good backup. This particular Jamf server is running on macOS. I haven't moved it to Linux yet. Something caused the /Library/Server/Wiki folder to fill up with backups, and it consumed the whole boot drive. And I'm not even running that service! So, when the database backup ran, the lack of disk space caused it fail. The backups are stored on a secondary internal SSD, but the lack of disk space on the boot drive where MySQL lives seems to have caused the database to become corrupted. All of my efforts to repair the database failed. Fortunately, no changes had been made to the JSS, and no systems were enrolled before this happened. I only lost a day's worth of data. How convenient that this happened on Labor Day weekend. I'm not sure if that's a blessing or if I should be annoyed 😐

One thing is for sure. As soon as possible, I'm moving this Jamf Pro instance to a Linux VM, just like the other one that I manage. Should anything horrible happen, I will also have the option of restoring the entire VM if needed.

[blinvisible]

Note that mysqlcheck can no longer repair database tables if you have converted to the InnoDB storage engine (as required by the Jamf Pro 10.10 installer).

https://dev.mysql.com/doc/refman/8.0/en/mysqlcheck.html

If mysqlcheck is unable to repair a table, see Section 2.11.13, “Rebuilding or Repairing Tables or Indexes” for manual table repair strategies. This will be the case, for example, for InnoDB tables, which can be checked with CHECK TABLE, but not repaired with REPAIR TABLE.

[autt]

with jamf 10.18 updating on one of my Ubuntu 18.0.4 systems now I am getting this error message when I open the webpage. I have run all steps per Rich and per turnere but so far no luck. I have enough space and there are other issues I can see with configuration files. tomcat8 and mysql are running fine and talking to each other... so it's been 2 hours of "Checking for tables to rename"

Update: after a new backup (had to run it twice) the server/webpage came online. I reviewed JAMFSoftwareServer.log and it detected a leak but I am happy it seems to be better through the magic of the jamf-pro binary