| Title: | SQL/Services Forum |
| Notice: | kits(3) ft info(7) QAR access (8) SPR access (10) |
| Moderator: | SQLSRV::MAVRIS |
| Created: | Thu Oct 13 1988 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2214 |
| Total number of notes: | 8586 |
SQL/Services V7.0 Standard Rdb V7.0 Never been a SQL/Services installation on this machine before I have been on the phone with a customer the last 2 hours trying to figure out why his GENERIC Executor won't start. We initially had problems with ipx/spx being defined in the dispatcher and he doesn't have that network protocol, so the dispatcher kept shutting down. We got by that problem so now the dispatcher stays up, but now we can't get a GENERIC executor process running. Why? I don't know. It doesn't leave an EXECUTOR log file in the SYS$SYSDEVICE:[SQLSRV$DFLT] directory. The only thing it leave is a .COM file with the filename the .log file is supposed to have. We have checked the dispatcher log, and it says the GENERIC executor failed to start see xxx.log file in a directory. We go there and there is no log file, just a .COM file. We tried to run the .COM file, but that didn't go far. We got file not found errors when a setver call tried to return to the command file, because it had already deleted itself. When we commented out the delete line, it got further, but stopped when sql/services tried to use some image (it didn't say which one) and said it didn't have the privileges to use it. According to the customer, they tried to do a sql/services install and it failes, so they installed sql/services client, then did the server piece again and it succeeded. Right now I'm at a loss for what the problem is. I have asked him to re-install the server again, see if that wakes something up so that it works again... Anyone have any ideas as to why we weren't getting log files, just com files? This sounds somewhat familiar, but I couldn't find anything on it. Thanks, Renee
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2197.1 | protection prob? | M5::JBALOGH | Thu May 08 1997 13:30 | 3 | |
Who is the owner of the directory for the default account?
John
| |||||
| 2197.2 | not sure... | BROKE::BASTINE | Thu May 08 1997 14:53 | 8 | |
This all worked after the initial install, so there are log files out there created before... now they don't work. I didn't explicitly ask who owned the directory as the .COM files were being created and there were other log files out there from earlier in the day.... Really frustrating problem.. Renee | |||||
| 2197.3 | Auditing and accounting? | chsr38.ch.oracle.com::RROHR | Cajun? Zeydeco? Both! | Fri May 09 1997 03:59 | 4 |
What does accounting say?
What do auditing alarms say?
/Regina
| |||||
| 2197.4 | John's right - check UIC's, prots + dflt disk:[dir] | ORASQS::OXBURY | Oracle Corporation, Rdb Desktop Group|DTN 381-2704 | Fri May 09 1997 10:47 | 22 |
Hi,
John probably has the answer to this one - if there's no .log file,
then the executor process is dying before it gets a chance to run
anything; including loginout. The usual reason for this is that
someone has changed the protection on the [SQLSRV$DEFLT] directory,
has changed the UIC of the directory file and/or has changed the
UIC of the SQLSRV$DEFLT account, or in some other way has changed
the SQLSRV$DEFLT account, for example, has changed the disk or
directory. As Regina suggested, enable accounting, try to start
an executor, then use the accounting/type=process/full/since=...
command to review the reason for the failure; typically, you will
see an RMS-F-NOPRV error, but it could be an RMS-F-NOSUCHDIR (or
something like that) if someone has altered the SQLSRV$DEFLT account.
On a different note: significant effort was made to ensure and test
that SQL/Services installs correctly on all supported platforms. If the
customer had a problem with the installation, then we need to know what
the problem was. There's no reason I can think of that should require
the client kit be installed before the server kit.
Si
| |||||
| 2197.5 | Thanks | BROKE::BASTINE | Mon May 12 1997 09:50 | 36 | |
> John probably has the answer to this one - if there's no .log file,
> then the executor process is dying before it gets a chance to run
> anything; including loginout. The usual reason for this is that
> someone has changed the protection on the [SQLSRV$DEFLT] directory,
> has changed the UIC of the directory file and/or has changed the
> UIC of the SQLSRV$DEFLT account, or in some other way has changed
> the SQLSRV$DEFLT account, for example, has changed the disk or
> directory. As Regina suggested, enable accounting, try to start
> an executor, then use the accounting/type=process/full/since=...
> command to review the reason for the failure; typically, you will
> see an RMS-F-NOPRV error, but it could be an RMS-F-NOSUCHDIR (or
> something like that) if someone has altered the SQLSRV$DEFLT account.
I went through the account with him at great lengths... making sure that
the account existing, directories were there... didn't check the ownership
on them, will do that today.
> On a different note: significant effort was made to ensure and test
> that SQL/Services installs correctly on all supported platforms. If the
> customer had a problem with the installation, then we need to know what
> the problem was. There's no reason I can think of that should require
> the client kit be installed before the server kit.
I told the customer they didn't need the client kit to install the server
part, but I think we're too late for trying to figure out what happened as
it did install OK.
I'll see how the second install went, if the problem still persists with
the failed executor, we'll use accounting to get to the bottom of it!
Thanks!
Renee (who smells another 2 hour call brewing... sigh)
| |||||
| 2197.6 | Disk quotas got us... | BROKE::BASTINE | Tue May 20 1997 10:05 | 16 | |
Went through the account with him again and again... all looked fine!! They didn't have accounting turned on and didn't want to turn it on. Kept telling the customer there is a reason those log files are not being created on those disks... but the account/protections all looked fine. The customer wanted to work with his system manager a bit and called me back to tell me they figured it out. Disk quotas were enabled on that disk and the two new accounts, SQLSRV$DEFLT and RMU$SRV didn't have any quotas to write to that disk. They are finally all set... thanks for all your suggestions... helped me not think I was going crazy... Renee | |||||