UNIX and Linux Applications

FWIW - lsnctrl starts a daemon.

There are errors that can occur after the parent process is detached/defunct and can no longer report an error. This is a common issue with a daemon starter script/program.

I would not expect a return code of failure except in the instance where you request, for example, a duplicate daemon instance. Most daemon drivers are coded to barf at the the very beginning in that case.

The daemon can fail independently and not report anything to the calling process when there are system errors, or there is a subsequent network error. That's why you have to scan logs rather than check return codes. IMO.

@radoulov: I pretty sure that I received the complete log, as it was sent automatically, and I wrote the script in question

@jim_mcnamara: IMHO any program/script that is a controlling interface between user and daemon (eg. init scripts, or lsnrctl in this case) shouldn't just limit themselves to the message "I've successfully sent the command to shut down completely", like it's happening here, but also tell me if the daemon in question can't act on that command. A simple "Sorry, I couldn't shut down, try again later" would be enough, and better than a default "Everything's shiny, move along".

That is a valid design complaint. Get on the phone with support. They used to listen.
Does metalink offer any help? I have not played DBA for many years, so I am not current.

When I was at Los Alamos, we worked with Oracle on an 'alpha' version of Oracle/sqlnet for the very first nationwide distributed dbms system. We had similar complaints back then - what we bitched about was exactly what you describe now - an 'all is well' from one object only to find an error later on. Which the first object should have done something about - at least complain.

Our problem was the then new sqlnet vs. VMS / MS-DOS