Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have Oracle 10g installed on RedHat Enterprise Linux 5.

I have 2 users that use Oracle:

uid=501(user1) gid=502(group1) groupes=500(oinstall),501(dba),502(group1)


uid=500(oracle) gid=500(oinstall) groupes=500(oinstall),501(dba),502(group1)

When a user tries to stop a listener that was started by the other user, I get this error:

TNS-01190: The user is not authorized to execute the requested listener command

How can I allow both users to stop the listener, regardless of who started it?

share|improve this question

migrated from Nov 12 '12 at 21:36

This question came from our site for professional and enthusiast programmers.

up vote 3 down vote accepted

The description for the message you're seeing is:

Cause: Most of the listener administrative commands are only intended to be issued by privileged users, for example DBAs or system administrators. If the listener password is not set, then the listener only accepts administrative requests from LSNRCTL running with the same OS credentials, or running as a local administrator (also referred to as super user).

Action: If an authorized user is attempting the command, then make sure that LSNRCTL is executed with the same OS user credentials as the running listener, or as a local administrator.

Unless you want to get into setuid wrappers, you need to have a password set for your listener. There's a good summary of how to set that up here, if you haven't already done so.

Then if you start the listener as normal as oracle, you can shut it down as user1 by going into the interactive mode of the controller, enter command 'set password', and enter the password for the listener:

$ lsnrctl

LSNRCTL for Solaris: Version - Production on 12-NOV-2012 14:55:29

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
TNS-01190: The user is not authorized to execute the requested listener command
LSNRCTL> set password
Password: <secret>
The command completed successfully
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
The command completed successfully

... and it should shut down. I know this is a different O/S and version but the principle is the same. And the reverse is true; if you start it as user1, you need to set password to be able to shut it down as oracle.

However, this is deprecated from 11gR2. The manual mentons using ssh or OEM, but you could also just make user1 switch to the oracle account to start and stop the listener via su. Obviously that gives them full DBA access, it isn't restricted to the listener, which is the case for ssh too.

I'm not sure why you'd want anyone you didn't trust to administer the database to be able to mess with the listener, or why you need to shut it down and start it up often enough for this to be an issue.

share|improve this answer
I'll add that having multiple users being able to do this is bad, and might not be supported. Just thinking that it's the listener process that does a fork() (maybe exec, my memory is bad) to establish a dedicated connection and the resulting process connects to a big shared memory segment. Security problems abound if the permissions are set accordingly. Just a thought. – Phil Nov 13 '12 at 1:32
@Phil - it is supported (or was, it's deprecated from 11gR2), but I originally had a comment querying why you'd want to do this, which I removed because I'd worded it unintentionally harshly. Agree that the security implications need to be given serious thought, but that's true for everything of course... – Alex Poole Nov 14 '12 at 11:16
Thanks @AlexPoole , I think i'm just gonna use setuid. when i do chmod 6755 lsnrctl then user1 can stop listener if started by oracle (but not the inverse) – Ould Abba Nov 18 '12 at 11:33
I wanted every body to be able to start and stop listener because i wrote some scripts witch changes the listener.ora and i want to restart the listener so changes will take effect for the rest of script. – Ould Abba Nov 18 '12 at 11:37
Changing permissions on an Oracle-installed binary, or messing with the installation at all unless under direction from Oracle Support, isn't generally a good idea. Apart from anything else, the binary might be relinked by a patch. I was thinking more of a setuid wrapper, possibly just restricted sudo. Just out of interest, what are you changing in the listener.ora? – Alex Poole Nov 18 '12 at 21:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.