Getting "Installation failed" on updates, even on success

WhoCares? wrote:
And lest I forget: Another cause may be (depending on the firmware version) that the script produces an error somewhen during it's run (or in case of ARM: produces some sort of output to STDOUT). This also will trigger the "Installation failed" message.

Oh, this is very likely to happen... I'll review my script and add a few redirects to /dev/null. Thanks for that hint!

The remove script does restart apache using "killall -USR1 apache-ssl". So as suggested replace this with

apache-ssl -f /etc/frontview/apache/httpd.conf -k graceful

mherger wrote:
How would I unpack an addon so I could run the script manually? It's not a simple tarball, is it?

#!/bin/bash
ARCH=`uname -m`
if [ "${ARCH}" == "padre" ]; then
  BSIZE=512
else
  BSIZE=16384
fi

if [ -f $1 ]; then
  TFIL=`basename $1 .bin`
  TFIL="${TFIL}.tar"
  dd if=$1 of=${TFIL} bs=${BSIZE} skip=1
else
  echo "Add-on file doesn't exist"
fi

From the top of my head so there may be syntax errors in there ;)

-Stefan

mdgm wrote:
The remove script does restart apache using "killall -USR1 apache-ssl". So as suggested replace this with apache-ssl -f /etc/frontview/apache/httpd.conf -k graceful

I prefer to use this:

/usr/sbin/apache-ssl -f /etc/frontview/apache/httpd.conf -t && /usr/sbin/apache-ssl -f /etc/frontview/apache/httpd.conf -k graceful

This makes sure that apache only gets restarted if it has a valid config. Prevents killing off Frontview ..

-Stefan

You of course want to create a directory and change the working directory to that before unpacking the add-on manually. Any files in the current working directory will be removed at the end of the install script.

So e.g.

cd /tmp/addons
mkdir SQUEEZE
cd SQUEEZE
wget http://downloads.slimdevices.com/nightly/7.7/sc/33813/logitechmediaserver-7.7.2-33813-arm-readynas.bin

Then run the script that WhoCares? suggested.

The directory e.g. /tmp/addons/SQUEEZE, must not be a directory mentioned by name in your install scripts or remove.sh scripts and must not be in files.tgz.

Guys - you rock! I found several places where messages were still sent to stdout, causing the failure message. start.sh/stop.sh as well as restarting httpd caused some messaging. Once all silenced the package now installs perfectly fine. Thank you both very much!

Michael

Oh well, I spoke too soon :-(. While I tested it several times successfully, it now seems to still fail.

I run install.sh as well as remove.sh manually and wouldn't see any message. If I run remove.sh -upgrade before the installation through the web UI, I wouldn't get the error message. Thus it's pretty clearly an issue in the remove.sh script. I _think_ it's related to restarting the httpd daemon.

When I run the initial wizard to create the basic addon, I told it that no server restart would be required. But the remove.sh still ended up with that line. When would httpd need to reload its configuration? Our server doesn't use it - shall I just leave it alone? Or will frontview always require the server to restart, as the add-on is adding some new virtual folder for its simple settings page?

Well, the thing is that the "RESTART_APACHE" thing is a bit misleading. What it means is that you should say "Y" there when you app absolutely requires Apache to be restarted. Now since every add-on comes with it's own tiny piece of Apache config, every add-on actually requires Apache to be restarted on install and removal ;) That's why the line in the remove.sh is present. On the older systems (Sparc, x86) this didn't hurt since install/upgrade/remove processes were started in their own subprocess and were working independently from Apache. On ARM however you'll have the same problem as with installing: since everything is now down in an Apache child process, killing Apache will effectively severe the communications channel between the process and it's monitoring Apache task. To fix this, either apply the same patch as given for the install part or remove the line completely for ARM. You may also want to check out my repo at https://gitorious.org/readynas to get a more sophisticated SDK - although I don't know whether I updated the remove.sh template with the workaround there already.

-Stefan