Mysql/greyhole/etc not working after /var adjustments

[mfs34]

After having my landing zone fill up very quickly, multiple times, resulting in a few predictable system crashes... I mounted a 3TB HDD as /var, edited /etc/fstab to reflect the change and rebooted. After powering back on it looks like the system (Amahi 7 Fedora), boots up and can startX, connect to internet and other normal functions. The problem seems to be that Mysql, greyhole, and other services are no longer starting now.

I'm not sure what the problem could be, but I'm guessing it had something to do with moving the /var dir data from one HDD to another. To move this data I booted into a live USB Ubuntu host and simply sudo mv'd the data from one dir to another, and then mounted that disk as /var in fstab. I imagine that simply sudo mv'ing the data did not disrupt the file permissions, but when I check services like sql status i get a confusing error:

Code: Select all

sudo service mysqld status Redirecting to /bin/systemctl status mysqld.service mysqld.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled) Active: failed (Result: exit-code) since Wed 2014-12-10 01:06:06 PST; 4s ago Process: 13032 ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID (code=exited, status=1/FAILURE) Process: 13031 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=1/FAILURE) Process: 13002 ExecStartPre=/usr/libexec/mysqld-prepare-db-dir %n (code=exited, status=0/SUCCESS) Dec 10 01:06:05 localhost.localdomain mysqld_safe[13031]: /usr/bin/mysqld_safe: line 182: /var/log/mysqld.log: Permission denied Dec 10 01:06:05 localhost.localdomain mysqld_safe[13031]: touch: cannot touch ‘/var/log/mysqld.log’: Permission denied Dec 10 01:06:05 localhost.localdomain mysqld_safe[13031]: chown: cannot access ‘/var/log/mysqld.log’: Permission denied Dec 10 01:06:05 localhost.localdomain mysqld_safe[13031]: chmod: cannot access ‘/var/log/mysqld.log’: Permission denied Dec 10 01:06:05 localhost.localdomain mysqld_safe[13031]: 141210 01:06:05 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended Dec 10 01:06:05 localhost.localdomain mysqld_safe[13031]: /usr/bin/mysqld_safe: line 138: /var/log/mysqld.log: Permission denied Dec 10 01:06:05 localhost.localdomain systemd[1]: mysqld.service: main process exited, code=exited, status=1/FAILURE Dec 10 01:06:06 localhost.localdomain systemd[1]: mysqld.service: control process exited, code=exited status=1 Dec 10 01:06:06 localhost.localdomain systemd[1]: Failed to start MariaDB database server. Dec 10 01:06:06 localhost.localdomain systemd[1]: Unit mysqld.service entered failed state.

But that file should have the correct permissions as seen below:

Code: Select all

sudo ls -al /var/log/mysqld.log -rw-r-----. 1 mysql mysql 106893 Dec 8 23:35 /var/log/mysqld.log

I have tried moving all of the /var data back to the original drive and reverting /etc/fstab, but no luck. It looks like Mysql just wont start. I really don't want to re-install so hopefully there is some fix possible.

Could a temporary outage of /var cause some sort of persisting issue with MySQL? My guess is that maybe Fedora tried to recreate some files it thought went missing in /var, but when it recognized that the data had returned the system may have stumbled?

I would show greyhole --stats info but that doesn't appear to be working either:

Code: Select all

sudo greyhole --stats ERROR: Can't connect to database: SQLSTATE[HY000] [2002] No such file or directory

[bigfoot65]

It is a BAD idea to mount /var to a separate drive in my opinion. The best way to combat the LZ issue is to mount /var/hda/files to a separate drive ONLY. This will account for all your shares which is the problem you have experienced. See moving landing zone for details. BTW the wiki is a good place to check for guidance.

Moving files can mess with the permissions, so this problem may just be the tip of the iceberg. It's likely your actions have broken Amahi and the OS. Trying to fix it may prove to be time consuming and not correct all problems. Sometimes you just have to cut your losses and start over.

My advice would to perform a reinstall. This will ensure you have everything right and less chance of issues in the future. The HDA OS Migration Guide should help with the reinstall.

[mfs34]

Hey Bigfoot, thanks for the response. Yeah I probably should have been more specific and mounted the drive as /var/hda/files as you suggested. Mounting the drive as /var probably borked everything. Damn. If anyone can think of potential fixes I would still be interested in trying to recover the installation, but re-installing Fedora 19/Amahi 7 probably is the best course of action.

I will need to look more into the migration wiki that you link, but I am concerned I may not be able to grab everything I need now that Mysql is hosed. Do you know if it is possible to follow along/rescue settings/users/etc with a downed Mysql server? Being that this whole mess started when the LZ reached capacity, I imagine I still have a ton of files that still need to be written into the Greyhole pool. I'd hate to sacrifice this data (roughly 300 GB?)

Woof..... what a bummer

[bigfoot65]

Hello,

Although MySQL is not working, many of the settings can be manually captured. You can check the directory structure for /var/hda/files to get the shares. As for users, you can pull that from the OS. Really not anything earth shattering that you could not retrieve with other methods.