Difference between revisions of "App troubleshooting"

From Amahi Wiki
Jump to: navigation, search
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
App install should '''never''' fail. Period. App install failures are high priority.
+
Application installs should <u>'''NEVER'''</u> fail. Period. App install failures are high priority to the [https://www.amahi.org/team Amahi Team].
  
 
= Debugability =
 
= Debugability =
Line 8: Line 8:
  
 
* Make sure httpd configuration is sane (result should be "'''Syntax OK'''"):  
 
* Make sure httpd configuration is sane (result should be "'''Syntax OK'''"):  
−
{{Code|httpd -t}}
+
httpd -t
  
 
* The idea is to not delete anything permanently - copy or move things to, say, a folder in /tmp if you have to get something out of their place. For example:
 
* The idea is to not delete anything permanently - copy or move things to, say, a folder in /tmp if you have to get something out of their place. For example:
−
{{code|mkdir /tmp/app-debug/}}
+
mkdir /tmp/app-debug/
  
 
* Then add things there as necessary for later analysis, like:
 
* Then add things there as necessary for later analysis, like:
−
{{Code|cp -a /var/log/amahi-app-installer.log /tmp/app-debug
+
cp -a /var/log/amahi-app-installer.log /tmp/app-debug
−
cp -a /etc/httpd/conf.d /tmp/app-debug}}
+
cp -a /etc/httpd/conf.d /tmp/app-debug
  
 
The user can provide this information:
 
The user can provide this information:
 
* Copy of the app install log:
 
* Copy of the app install log:
−
{{Code|tail -300 /var/log/amahi-app-installer.log <nowiki>|</nowiki> fpaste}}
+
<blockquote><u>Fedora</u></blockquote>
 +
tail -300 /var/log/amahi-app-installer.log | fpaste
  
−
* Copy of the app error and access logs (i.e. sabnzbd is the app):
+
<blockquote><u>Ubuntu</u></blockquote>
−
{{Code|cat /var/hda/web-apps/sabnzbd/logs/error.log
+
tail -300 /var/log/amahi-app-installer.log | apaste
−
cat /var/hda/web-apps/sabnzbd/logs/access.log}}
+
 
 +
* Copy of the app error and access logs (i.e. Adminer is the app):
 +
cat /var/hda/web-apps/adminer/logs/error.log
 +
cat /var/hda/web-apps/adminer/logs/access.log
  
 
* To check if process is running (i.e. sab is the app):
 
* To check if process is running (i.e. sab is the app):
−
{{Code|ps guax <nowiki>|</nowiki> grep sab <nowiki>|</nowiki> fpaste}}
+
<blockquote><u>Fedora</u></blockquote>
−
 
+
ps guax | grep sab | fpaste
−
= Miscellaneous =
 
−
* Filesystems are corrupted, due to a power failure or system crash. Generally, after a system crash or power outage (what? No UPS?), the system will come up and repair itself. If you are using a journalling filesystem like ext3fs, jfs, xfs or resiserfs, it will usually perform a roll-forward recovery from its journal file and carry on. Even with the older ext2fs, the system usually runs an fsck (file system check) on the various file systems and repairs them automatically. However, just occasionally manual intervention is required - ; you might have to answer 'Y' to a string of questions (answering 'N' will get you nowhere unless you intend to perform really low-level repairs yourself in a last-ditch attempt to avoid data loss). In the worst case, you might have to reboot from rescue media and manuall run the e2fsck (or similar) command against each filesystem in turn. For example:
 
−
{{Code|e2fsck -p /dev/hda7}}
 
−
 
 
−
* If the program complains that the superblock - the master block that links to everything else - is corrupted, it is useful to remember that the superblock is so critical that it is duplicated every 8192 blocks through the filesystem and you can tell e2fsck to use one of the backups:
 
−
{{Code|e2fsck -b 8193 /dev/hda7}}
 
  
−
* One or more filesystems cannot be found and mounted: Check the contents of /etc/fstab - in making quick alterations here, typographical errors are common. You can use the e2label command to view the label of each filesystem: some distributions set these to the mount point so you can figure out what is what.
+
<blockquote><u>Ubuntu</u></blockquote>
 +
ps guax | grep sab | apaste

Latest revision as of 23:08, 6 August 2014

Application installs should NEVER fail. Period. App install failures are high priority to the Amahi Team.

Debugability

Debugging app install issues is very important, so any time something permanently destructive is attempted, it should be done with care to preserve the ability to analyze and debug what happened:

  • Preserve as much as possible from the existing (buggy) environment
  • Make sure httpd configuration is sane (result should be "Syntax OK"):
httpd -t
  • The idea is to not delete anything permanently - copy or move things to, say, a folder in /tmp if you have to get something out of their place. For example:
mkdir /tmp/app-debug/
  • Then add things there as necessary for later analysis, like:
cp -a /var/log/amahi-app-installer.log /tmp/app-debug
cp -a /etc/httpd/conf.d /tmp/app-debug

The user can provide this information:

  • Copy of the app install log:

Fedora

tail -300 /var/log/amahi-app-installer.log | fpaste

Ubuntu

tail -300 /var/log/amahi-app-installer.log | apaste
  • Copy of the app error and access logs (i.e. Adminer is the app):
cat /var/hda/web-apps/adminer/logs/error.log
cat /var/hda/web-apps/adminer/logs/access.log
  • To check if process is running (i.e. sab is the app):

Fedora

ps guax | grep sab | fpaste

Ubuntu

ps guax | grep sab | apaste
Retrieved from "https://wiki.amahi.org/index.php?title=App_troubleshooting&oldid=86446"