Database update failure after image capture
-
@Sebastian-Roth I have supplied output as requested
-
@MikeBC We need to figure out why you get HTTP 503. As you can obviously use the FOG web UI to schedule new tasks it doesn’t seem to be a general Apache/PHP issue. So please schedule another task and let the host run the task. Meanwhile open a root shell on your FOG server and run
tail -f /var/log/php-fpm/* /var/log/httpd/error_log
(note there is a space between the two) to see what messages come in when the task finishes and shows the error message. -
@Sebastian-Roth I have attached logs as requested
-
@MikeBC What time did you run the task? I only see a few log messages for today. Which error did you get on the screen this time?
-
@Sebastian-Roth I ran the task at about 10H30 or so. I wasn’t in front of the PC at the time to verify error on completion. I will run it again shortly and provide error message again.
-
@MikeBC Looking through the logs again I saw this at the bottom end:
[Mon Oct 05 10:29:844700 2020] [proxy_fcgi:error] [pid 55573] (70007)The timeout specified has expired: [client 10.0.3.129:45100] AH01075: Error dispatching request to :
I can’t make sense of this as you don’t seem to have many clients or others sending in requests that would cause I high load on Apache and PHP-FPM. Searching the forum a bit I found this similar sounding topic that seems to never have been solved: https://forums.fogproject.org/topic/14563/snapin-problem-on-fog-1-5-9-rc1-and-1-5-9-rc2
The other error messages we see from today are related to the FTP commands used to rename
/images/dev/f8bc1265c913
to it’s destination in/images/...
. I really wonder if/images/dev/f8bc1265c913
really exists at this point?? It should be created when the machine runs the task to temporarily store the uploaded image files. Please runls -al /images/dev/f8bc1265c913
and post output here. -
@Sebastian-Roth I ran the capture twice once to the /images/Client directory and then to the /images/ directory both times same error occurred that I have been experiencing. I have attached output.
-
@MikeBC Seems like it’s not creating the upload directory or maybe it does but in a different place. Please run these commands (again) and post output here:
ls -al /images/dev cat /etc/exports
We can also switch to chat for faster turnaround - chat bubble in the right top corner.
-
[root@imagingout ~]# ls -al /images/dev total 0 drwxrwxrwx. 6 fogproject root 130 Oct 6 08:20 . drwxrwxrwx. 10 fogproject root 186 Oct 6 08:21 .. drwxrwxrwx 2 fogproject root 190 Mar 20 2020 082e5f1dface drwxrwxrwx 2 fogproject root 222 Jan 14 2020 64006a486167 drwxrwxrwx 2 fogproject root 6 Apr 30 15:39 ecf4bb70a96c -rwxrwxrwx. 1 fogproject root 0 Oct 11 2019 .mntcheck drwxrwxrwx. 2 fogproject root 34 Oct 11 2019 postinitscripts [root@imagingout ~]# cat /etc/exports /images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1) [root@imagingout ~]#
-
Looks there was finally as solution. I ran yum update -y today and after a server reboot the image capture with database update worked 100%. I must thank @Sebastian-Roth for assisting me in the chat bubble running various scripts and looking many possible fixes to try remedying the issue experienced. The support received was fantastic, thank you kindly.
-
@MikeBC In your last picture of /images/dev directory. There are several directories there with mac looking addresses. These are botched uploads. You can delete the directories and its contents they are just taking up space.
rm -rf /images/dev/082e5f1dface rm -rf /images/dev/64006a486167 rm -rf /images/dev/ecf4bb70a96c
unless you are currently capturing an image you should never have mac style named directories in /images/dev
-
@george1421 Thank you. I will delete them shortly to avoid any further issues.