php exec() function and linux shell command

[journey4712]

First i would try running the daemon.sh script by itself, just make sure its all legit

Code:

cd /share/Apps/Shutdown
./daemon.sh start

if running daemon.sh yourself gets the file copied over, then i think should be just fine. Also if something is already started use the following

Code:

/share/Apps/AppInit/appinit.cgi restart Shutdown

journey4712

[highonhd]

(08-07-2009 09:22 PM)journey4712 Wrote:  First i would try running the daemon.sh script by itself, just make sure its all legit

Of course I should have thought of that ..doh

Yes the daemon script is perfect ( never doubted it )
It copies over the shutdown.cgi file file.

So I deleted it for the next test and ran

Code:

/share/Apps/AppInit/appinit.cgi restart Shutdown

and the shutdown.cgi is still not getting copied over.
Which means CSI /appinit.cgi is not working.

Does CSI install a service/server of some type that will start at boot up ?
I gave been to Ger's website and nothing is mentioned.

What I don't get is: what causes appinit.cgi to run at boot up ?

I think I am missing something

[journey4712]

appinit.cgi is run whenever the ftp server is started/stopped. You can verify appinit is in there with a grep

Code:

grep appinit /mnt/syb8634/etc/ftpserver.sh

I cant think of why daemon.sh isn't starting for you, it always works locally for me. Just dig through a bit bound to find something

journey4712

[highonhd]

(08-07-2009 10:54 PM)journey4712 Wrote:  appinit.cgi is run whenever the ftp server is started/stopped. You can verify appinit is in there with a grep

Code:

grep appinit /mnt/syb8634/etc/ftpserver.sh

I cant think of why daemon.sh isn't starting for you, it always works locally for me. Just dig through a bit bound to find something

journey4712

Ah ok now I get it. Yup appinit.cgi is in ftpserver.sh so that bit is correct.
Almost there....will keep digging ...got to be something simple

Thanks for your teaching and help.

[highonhd]

OK.....cracked it !!

problem was with appinfo.json file.

journey4712 had :

Code:

daemon="daemon.sh"

It should have been:

Code:

daemon_script="daemon.sh"

took a while with lots of debug statements in appinit.cgi to find why daemon.sh was not not being called.

This highlights a slight flaw in CSI in that it does not validate or enforce strict format for appinit.json file.

Also changed daemon.sh so that the SHUTDOWN.CGI is removed if STOP is ever called. New daemon.sh :

Code:

#!/bin/sh

SCRIPT="shutdown.cgi"
SOURCE=$(echo $0 | sed 's,[^/]*$,,')
DEST="/opt/sybhttpd/default"

if [ x"$1" == x"start" ]; then
   cp $SOURCE/$SCRIPT $DEST/
   chmod +x $DEST/$SCRIPT
   exit
fi

if [ x"$1" == x"stop" ]; then
   rm $DEST/$SCRIPT
fi

[Ger Teunis]

(08-08-2009 01:16 AM)highonhd Wrote:  This highlights a slight flaw in CSI in that it does not validate or enforce strict format for appinit.json file.

It is not a flaw, it is by design.
The file is rather simple and good documentation is available how to create the file. Almost all items in the appinfo.json file are, and will remain optional as well as it will not give an error on (currently) unsupported items. This is done to allow future backwards and forwards compatibility.

I could on the other hand add a warning when an unsupported item has been encountered, that might help in incorrect compiled files.

[journey4712]

@highonhd

my apologies, i thought i compared the appinfo.json directly from a working application, but aparently i missed something obvious

At least it gave you a chance to learn more about how the CSI works

journey4712

[Ger Teunis]

@Highonhd

Perhaps you want more background information.
More information regarding creating packages is available here:
http://nmtinstaller.com/?p=createpackage

Especially the "Creating packages using AppInit" link will be a good read for you I guess.

[highonhd]

(08-09-2009 06:26 PM)Ger Teunis Wrote:  I could on the other hand add a warning when an unsupported item has been encountered, that might help in incorrect compiled files.

Hi Ger I understand the logic of not checking for unsupported fields. Adding a warning, IMHO, is much better suggestion. You could add a warning such as "Unsupported mandatory or optional field. Please check the exact name and change if incorrect"....or words to that effect.
Thanks

---

(08-09-2009 10:47 PM)journey4712 Wrote:  @highonhd

my apologies, i thought i compared the appinfo.json directly from a working application, but aparently i missed something obvious

At least it gave you a chance to learn more about how the CSI works

journey4712

Hi Journey4712, no problem at all. It was worth the detour as I did learn quite a bit . Many thanks for your help.

BTW, is there good guide for learning to write .cgi scripts for html output somewhere ?
I do not see onything on the wiki.

---

(08-10-2009 12:03 PM)Ger Teunis Wrote:  @Highonhd

Perhaps you want more background information.
More information regarding creating packages is available here:
http://nmtinstaller.com/?p=createpackage

Especially the "Creating packages using AppInit" link will be a good read for you I guess.

Thanks. I had read through that page. Feedback: I think it's worth adding an example of how to tar the package together on your PC or on your NMT (with the exact tar command line).[/u]