#254797 - 23/04/2005 11:45
Hijack & ;@MENUEXEC
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
This is probably specifically a Mark question. When executing these menu additions:-
- What PATH is available?
- What difference does 'exec' make?
- A reboot is required after changes in config.ini?
- Is it safe to kill the player app while executing a script from the menu?
- Likewise 'killall -HUP bash'?
I have a script that kills the player, runs rsync (as a client) and then kills bash, but it gets stuck with rsync still running, yet this script runs perfectly from the (telnet) command line. I'm wondering what could be the problem. ????
|
|
Top
|
|
|
|
|
#254798 - 23/04/2005 13:35
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Further research reveals that although Hijack cannot find the script in /usr/local/bin (so I have to specify the full path in config.ini) it does seem to find rsync which is in /usr/bin. So there does seem to be a default path set somewhere, although it doesn't get it from /etc/profile.
I've also determined that the script gets as far as running rsync, but which never finishes. If I manually kill rsync from the commandline the script continues as it should.
Why would rsync be getting stuck like this?
Could it be a display problem? I'm using Pim's rsync that displays progress on the VFD. But does Hijack grab that for the menu display? Would that cause rsync to halt?
|
|
Top
|
|
|
|
|
#254799 - 23/04/2005 16:22
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Update - in fact if I run my script from a 'site exec etc' command via ftp it also gets stuck with rsync.
To recap, this shell script works perfectly from a telnet terminal, but NOT from the Hijack menu or by 'site exec...'
So, it appears that rsync won't run properly if there's no terminal involved, even though it's not actually printing to it as I'm capturing the output for manipulation first.
I can only think it's rsync because everything prior is executed, rsync runs but nothing after gets done until I kill the 2 rsync processes that are started.
The code I'm using is:-
killall -INT player
swapon -a
rwm
RioSYNCout=$(rsync \
$OPTS \
--empeg-progress \
--stats \
--times \
--recursive \
--delete \
--copy-unsafe-links \
--exclude=config.ini \
--exclude=lost+found \
--exclude='\.*' \
$RSYNCSERVER::empeg/drive? / ) || die 8 "Oops - RSYNC error $?"
rwm executes and then rsync, but nothing more until I kill rsync, then 'die' displays the RSYNC error message - return code is 137, but I suspect that is due to me killing the processes.
I also tried it without the --empeg-progress option but it made no difference.
I'm stumped - any suggestions?
|
|
Top
|
|
|
|
|
#254800 - 24/04/2005 00:38
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14483
Loc: Canada
|
Try pausing after the killall, to give time for the player to catch the SIGINT and actually exit before the next steps..
??
|
|
Top
|
|
|
|
|
#254801 - 24/04/2005 00:40
Re: Hijack & ;@MENUEXEC
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14483
Loc: Canada
|
Or use: killall -w -INT player
|
|
Top
|
|
|
|
|
#254802 - 24/04/2005 05:53
Re: Hijack & ;@MENUEXEC
[Re: mlord]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Quote:
Try pausing after the killall, to give time for the player to catch the SIGINT and actually exit before the next steps..
Why would that make a difference? It currently works great when the script is run from the (telnet) commandline and only fails when run from either the Hijack menu or an ftp site exec command.
It is this inconsistent behaviour that surely must be the key?
Anyway, I tried killall -w..... and it made no difference.
It really does seem to me that it's an rsync thing, but I've no idea what, or how to cure it.
|
|
Top
|
|
|
|
|
#254803 - 24/04/2005 05:58
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
One other perhaps relevant point is that if I comment out the rsync command from the script, it runs perfectly, although doesn't do much of course.
BTW, Mark, what about my first 2 original questions. What PATH is available when executing from the menu and why is 'exec' recommended?
Thanks.
|
|
Top
|
|
|
|
|
#254804 - 24/04/2005 14:30
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14483
Loc: Canada
|
Use the Source, Luke!
static char *envp[] = { "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };
As for exec, it's simply a way to save memory, by having the shell do a exec() system call directly to run your command, rather than first forking off a child process to do it. Not having the shell active in memory means more RAM available for your app.
Cheers
|
|
Top
|
|
|
|
|
#254805 - 24/04/2005 14:36
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14483
Loc: Canada
|
The main difference between you running the script from a telnet (or serial) connection, is that there will be an "attached terminal", and stdin will point at it.
When running from Hijack (either from FTP or MENUEXEC or the other Hijack mechanisms), Hijack explicitly points stdin at /dev/null to prevent the program locking up trying to read from standard input. It does, however, attempt to point both stdout and stderr at /dev/consle (the serial port). The filesystem, session, signal handling, and other process attributes are all set to be those of init (the root of all processes).
I'm betting your rexec woes have something to do with stdin. You should hook up a serial cable and watch for error messages on the serial console, while running the script remotely from FTP (over ethernet) or whatever.
Cheers
|
|
Top
|
|
|
|
|
#254806 - 24/04/2005 15:29
Re: Hijack & ;@MENUEXEC
[Re: mlord]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
I kinda figured it was an 'attached terminal' problem.
At your suggestion, I just ran it again with a serial terminal attached - here's the result:
sync neXus's music...
Restored terminal settings
Remounting first music partition read-only
Remounting second music partition read-only
Adding Swap: 16596k swap-space (priority -31)
Abnormal player termination
Player received SIGINT, user interruption
Switching to shell-player loop
Starting bash.
Adding Swap: 16028k swap-space (priority -32)
empeg:/empeg/bin# EXT2-fs warning: maximal mount count reached, running e2fsck i
s recommended
EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
*********************
Shell exit
Starting player
Timezone: Europe/London
Hijack: intercepting config.ini
player.cpp : 385:empeg-car 2.00 2003/04/01.
Prolux 4 empeg car - 2.1434 Mar 26 2003
Vcb: 0x4086d000
The first line is my script echoing that text and the fsck warning is hardly surprising after all the mounting and unmounting I've been doing, but I don't expect that to make any difference. Apart from that, there's no real obvious errors. ******** is where the script runs and rsync hangs so I have to kill it.
I did run the whole thing with files missing on the empeg and rsync seemed quite happy to actually perform the transfers, but then stopped at the end and never exited.
Since it doesn't appear to a problem with output, this would suggest that rsync has a problem with stdin pointing to /dev/null. Is there any way to circumvent that? Or any other solutions spring to mind?
|
|
Top
|
|
|
|
|
#254807 - 24/04/2005 15:32
Re: Hijack & ;@MENUEXEC
[Re: mlord]
|
carpal tunnel
Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
|
You could try putting this as the first line of your script: Code:
exec 0<&- 0>&- 1>&-
which will explicitly close stdin, stdout, and stderr.
_________________________
Bitt Faulk
|
|
Top
|
|
|
|
|
#254808 - 24/04/2005 16:18
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Quote:
I have a script that kills the player, runs rsync (as a client) and then kills bash, but it gets stuck with rsync still running
If you run your script from a shell spawned by telnetd, this shell will be the process group leader for every process you will start from this shell. If you give this shell a hangup signal, normal *ix behaviour is that every process that is in the same process group, *and* that is attached to the same terminal, will inherit this signal.
If you run your script from hijack, there will be no terminal attached, so all the programs you start will act as daemons.
The simple solution for your particular problem might be to killall rsync, although I don't understand why rsync does not exit when it is finished.
Pim
Edited by pim (24/04/2005 16:43)
|
|
Top
|
|
|
|
|
#254809 - 24/04/2005 16:42
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Quote:
What PATH is available?
Like Mark responded, hijack sets the PATH itself, and does
not include /usr/local/bin. The shell which runs on the serial
port has its PATH set in /sbin/init, which does include /usr/local/bin.
telnetd resets the PATH and dos not include /usr/local/bin.
To circumvent this, I start telnetd from a script that first
sets the PATH, and then starts telnetd. This script is then
started from hijack.
Pim
|
|
Top
|
|
|
|
|
#254810 - 25/04/2005 06:23
Re: Hijack & ;@MENUEXEC
[Re: wfaulk]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Quote:
You could try putting this as the first line of your script:
Code:
exec 0<&- 0>&- 1>&-
which will explicitly close stdin, stdout, and stderr.
Nope, still gets stuck :-(
|
|
Top
|
|
|
|
|
#254811 - 25/04/2005 06:27
Re: Hijack & ;@MENUEXEC
[Re: pim]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Quote:
Quote:
What PATH is available?
hijack sets the PATH itself, and does
not include /usr/local/bin.
Pim
In fact the only thing in /usr/local/bin is the actual script and I start that with its full pathname, but I tried putting a full PATH command at he beginning of my script and it made no difference.
|
|
Top
|
|
|
|
|
#254812 - 25/04/2005 06:32
Re: Hijack & ;@MENUEXEC
[Re: pim]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Quote:
Quote:
I have a script that kills the player, runs rsync (as a client) and then kills bash, but it gets stuck with rsync still running
The simple solution for your particular problem might be to killall rsync, although I don't understand why rsync does not exit when it is finished.
Pim
It requires killall -9 rsync, but how can the script run this? Since rsync never exits, the script never gets to its next line, until rsync is manually killed.
Even if I could, I wouldn't like it as a solution, I'd much rather find out why rsync has this problem and fix it. Ha, if it's possible.
|
|
Top
|
|
|
|
|
#254813 - 25/04/2005 19:46
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14483
Loc: Canada
|
Okay, see if you can telnet in while rsync is hung, and dump out the process status for it to see what state it is in.
-ml
|
|
Top
|
|
|
|
|
#254814 - 25/04/2005 20:12
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
Quote:
Code:
RioSYNCout=$(rsync \
$OPTS \
--empeg-progress \
--stats \
--times \
--recursive \
--delete \
--copy-unsafe-links \
--exclude=config.ini \
--exclude=lost+found \
--exclude='\.*' \
$RSYNCSERVER::empeg/drive? / ) || die 8 "Oops - RSYNC error $?"
Having rsync started within $( ... ) is responsible for forking off a subshell. It might be this subshell that is hanging.
Your drives are mounted read/write when you rsync. Why don't you just redirect the output to a file? This will save an extra process.
Pim
|
|
Top
|
|
|
|
|
#254815 - 26/04/2005 06:08
Re: Hijack & ;@MENUEXEC
[Re: pim]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Quote:
Having rsync started within $( ... ) is responsible for forking off a subshell. It might be this subshell that is hanging.
Your drives are mounted read/write when you rsync. Why don't you just redirect the output to a file? This will save an extra process.
I thought the same so ran it without capturing the output at all, i.e. just a direct rsync ..... command and it made no difference.
The reason I capture to a variable is that during the sync root is still ro and this way I only set rw at the end, write the stats to a file and then set the whole lot ro. Just means that if it all goes pearshaped during the sync, at least root should be safe.
It's a small point but, it doesn't make any difference to this problem.
|
|
Top
|
|
|
|
|
#254816 - 26/04/2005 09:59
Re: Hijack & ;@MENUEXEC
[Re: ukengb]
|
addict
Registered: 14/11/2000
Posts: 474
Loc: The Hague, the Netherlands
|
You could create a directory /drive0/tmp and use that.
Pim
|
|
Top
|
|
|
|
|
#254817 - 26/04/2005 19:17
Re: Hijack & ;@MENUEXEC
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14483
Loc: Canada
|
Quote:
Okay, see if you can telnet in while rsync is hung, and dump out the process status for it to see what state it is in.
Or even just grab the process status from /proc using the Hijack webserver.
|
|
Top
|
|
|
|
|
#254818 - 27/04/2005 05:14
Re: Hijack & ;@MENUEXEC
[Re: mlord]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Quote:
Quote:
Okay, see if you can telnet in while rsync is hung, and dump out the process status for it to see what state it is in.
Or even just grab the process status from /proc using the Hijack webserver.
'Sfunny, I thought I had replied to your original message, but I can't see it. Must be me.
If you can describe what to look for in /proc, I'd be happy to dig around in there, but it's not something with which I'm familiar.
Anyway, yes I can telnet in, no problem. The exit status of rsync after I manually kill it is 137, but I've no idea what that means. Or did you mean the status of the script? How would I get that?
|
|
Top
|
|
|
|
|
#254819 - 27/04/2005 05:16
Re: Hijack & ;@MENUEXEC
[Re: pim]
|
member
Registered: 30/04/2003
Posts: 136
Loc: United Kingdom
|
Quote:
You could create a directory /drive0/tmp and use that.
Pim
I could, but it doesn't help. Capturing the output is not the problem. It hangs even without that:-(
|
|
Top
|
|
|
|
|
|
Previous Topic
Index