Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

better startNetldi script error messages #86

Open
dalehenrich opened this issue Sep 9, 2015 · 4 comments
Open

better startNetldi script error messages #86

dalehenrich opened this issue Sep 9, 2015 · 4 comments

Comments

@dalehenrich
Copy link
Member

Here's a stack dumpe:

craig@ubuntu bin 5> ./startNetldi roassal
GsDevKit script: startNetldi roassal
starting netldi roassal
GsDevKit script: tode startnetldi roassal
Error running shell command: '/home/craig/gsDevKitHome/gemstone/stones/roassal/product/bin/startnetldi'
with args:
-l
/home/craig/gsDevKitHome/gemstone/stones/roassal/logs/netldi.log
-g
-a
craig
roassal_ldi
STDOUT: 'startnetldi[Info]: GemStone version ''3.2.6''
'
STDERR: startnetldi[Error]: 'roassal_ldi' already exists but is not responding.
Error: Shell command: '/home/craig/gsDevKitHome/gemstone/stones/roassal/product/bin/startnetldi' failed.
GsDevKitStartnetldiCommandLineHandler class(Object)>>error:
GsDevKitStartnetldiCommandLineHandler class(GsDevKitAbstractCommandLineHandler class)>>runShellCommand:args:noError:
GsDevKitStartnetldiCommandLineHandler(GsDevKitAbstractCommandLineHandler)>>runShellCommand:args:
GsDevKitStartnetldiCommandLineHandler>>activate
GsDevKitStartnetldiCommandLineHandler class(CommandLineHandler class)>>activateWith:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ]
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc...
BlockClosure>>on:do:
PharoCommandLineHandler(BasicCommandLineHandler)>>activate
PharoCommandLineHandler>>activate
PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ]
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
MorphicUIManager>>spawnNewProcess in Block: [ ...
BlockClosure>>newProcess in Block: [ ...
craig@ubuntu bin 6>

The actual error was STDERR: startnetldi[Error]: 'roassal_ldi' already exists but is not responding. so dumping the STDERR output first would be an improvement.

Even better would be to include a suggestion as to what steps should be taken ... in this case kill the process associated with 'roassal_ldi' and try again ...

@marianopeck
Copy link

For the record...recently I got this error too and the error description was misleading too. STDERR: startnetldi[Error]: 'roassal_ldi' already exists but is not responding. was not 100% correct because in my case the ldi DID NOT existed...but did existed and was causing the problem is the lock file of the netldi. Probably some dirty shutdown or whatever killed netldi without removing the lock. So....it took me some time to realize I had to explicitly remove the lock file.

@dalehenrich
Copy link
Member Author

Good point @marianopeck the lock file is the "proof of life" for the netldi ... in fact your observation leads me to believe that I can "avoid thsese errors in the future", because one can use gslist -c to clean up stale lock files ... I can arrange for this command to at least do that much ... THX!

@marianopeck
Copy link

Sure, good idea about using gslist -c. However, as far as I remember I had problems with gslist -c doing nothing, in the sense that it would NOT delete the lock file in question. Don't remember if it was a permission/owner issue or something else (pointing to a wrong folder?). But I do remember having to delete using rm because gslist -c would not do it. So..you may want to double check after performing the gslist -c that the file is indeed deleted (most of the time you have at least read access to the file). If not you can throw a message saying human intervention to delete such file is needed.

@dalehenrich
Copy link
Member Author

good point!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants