I'm trying to create a database using DBCA on Oracle 11g installation on Ubuntu Linux 12.04 64 bit.
I followed the instructions here, but I get
ORA-12547: TNS Lost Contact when running DBCA.
Below are the details. Can someone assist with the solution?
Instead of using /opt/oracle as the "oracle" user home, I used /home/oracle
I did not install the libstdc++5 in 32 bit version
I did everything else the same as the posting
Installation resulted in "missing packages". I tried to do an apt-get install for these packages from ubuntu, but ubuntu says that they don't exist.
Then I saw in the instructions:
Once you will reach the "pre-reqs" screen, check "Ignore all" to continue the installation.
When running ./dbca from $ORACLE_HOME/bin, it fails with ORA-12547.
I checked $ORACLE_HOME/network/admin and listener.ora , sqlnet.ora , and tnsnames.ora all look OK.
However, I think that tnsnames.ora is not being read properly, because ./tnsping fails and the error message states that "EZ Connect" was used.
But in my sqlnet.ora , I have
names.directory_lookup = (TNSNAMES,EZCONNECT)
It should use EZ Connect only after tnsnames is tried.
Also, I sometimes get ORA-12541: No listener. I tried running ./netca. Everything is OK until I perform a test on the listener, and it fails.
I can't run ./lsnrctl. Absolutely nothing happens for this, as well as lsnrctl start, stop, status.
I can't go through sqlplus. If I run ./sqlplus , it asks me for username/password directly.
If I do ./sqlplus / as sysdba, then this results in "ORA-12547: TNS lost contact".
All environment variables are set correctly in .bashrc.
I tried re-running root.sh , but the problem is not fixed.
/etc/oratab is OK
/etc/hosts is OK, but I can't always ping the "localhost" or "127.0.0.1", or "ubuntu" or "127.0.1.1"
The same TNS or Listener errors display.
When I login in oracle (sqlplus system/pass as sysdba), I got this:
ERROR:
ORA-12547: TNS :lost contact when try to connect to Oracle.
First, I think the server is down, but I check it, it is OK. And so many body say 'chmod 6751 oracle', I did it, but I got another error:
ERROR:
ORA-01031: insufficient privileges
Enter user-name:
finally, I switch the system user from root to oracle. And I login success.
Ensure the DB is up and running and you can connect locally AS SYSDBA to the database
using Oracle binaries owner (usually oracle:oinstall Unix / Linux user). If it does not
work, probably you encounter a different problem.
1. Check privileges of an Oracle file on Unix / Linux host where database is running:
cd $ORACLE_HOME/bin
ls -ltr oracle
2. Change permissions as below:
chmod 6751 oracle
ls -ltr oracle
This code may help you lot.
Related
On a new Windows Server 2016 PC:
signed on as administrator
Fresh install of 19c with default orcl database. No issues during install
Installed full 32-bit 11g client (needed for connection to legacy app) no install issues
added SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11 to sqlnet.ora
tnsping orcl ran and showed connection
sqlplus /nolog
connect / as sysadm
returned ORA-12560 TNS Adapter: protocol adapter error
Both listener and orcl services are running (tried restarting them but still got error)
Tried setting $TNS_ADMIN and $ORACLE_HOME but error still occurs.
Tried rebooting but no change.
PATH has client oci.dll folder listed first then ORACLE HOME folder
Pulling hair out has commenced...
I'm new to Oracle database, but I had a similar problem while installing Oracle 21DB express. I kept installing and uninstalling because I could not get past the login/password. It kept giving me
"ORA-12560 TNS Adapter: protocol adapter error"
what I finally did was on my last installation, on the setup.exe, you must right click on the mouse and "run as administrator". Then everything ran perfectly. Also while researching I was told don't have more than 1 version of SQL on a machine.
I am trying to run jupyterhub on an Ubuntu 20.04 LTS server. My idea is to run python/jupyterhub in a conda virtual environment as a system service. As I want to be able to limit the resources available to individual users I installed the systemdspawner.
After installing everything and starting the jupyterhub service I can login through my web browser. However, when trying to start the server the spawner stucks and after a while I get an error message saying "Spawn failed: Timeout"
in journalctl I can see the following messages:
User logged in: me 302 POST /hub/login?next= -> /hub/spawn (me#::ffff:[my IP address]) 59.42ms
Adding role server to token: <APIToken('93c8...', user='me', client_id='jupyterhub')
Creating oauth client jupyterhub-user-me
pam_loginuid(login:session): Error writing /proc/self/loginuid: Operation not permitted
pam_loginuid(login:session): set_loginuid failed
pam_unix(login:session): session opened for user me by (uid=0)
Failed to open PAM session for me: [PAM Error 14] Cannot make/remove an entry for the specified session
Disabling PAM sessions from now on. user:me
Unit jupyter-me-singleuser in a failed state. Resetting state.
Disclaimer: My Jupyter/Python installation is replacing an former installation that was setup by someone else and got messed up a bit during time. I tried to remove everything related and start with a clean installation from scratch. However, as I had very little documentation about the old setup there is a certain risk that there might be some left-overs of the previous installation that may cause trouble.
Any ideas?
Solved it out myself. In the end the PAM related messages seem to be non-critical and were not related to the timeout at all. Instead I found a mistake in /etc/systemd/system/jupyterhub.service, where the PATH variable was not including the bin directory of my miniconda installation.
a have upgraded my DB server from 10.1.36 to 10.2.30 and after running command mysql_upgrade it fail at step 4. Please take a look on screenshot. Does anybody have idea what is wrong?
I believe you have to give mysql users read and execute permissions to /var/log/ and /var/log/mysql/ directory, before it can access /var/log/mysql/slow_log.CSV file.
I already installed OpenCPU on a Ubuntu Server - Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-32-generic x86_64) - and everything worked perfectly without any problems.
Here I want to say that I really like this API and I am very thankful for all the effort from the people (I think mostly Jeroen Ooms) working on it.
Now I installed it again, but on another Server hosted at another provider. It is also a Ubuntu Server - Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-042stab093.4 x86_64) - and therefore I expected it to work as smoothly as before.
But now I have a problem. After the installation and starting the service, I wanted to check through my browser if everything is OK.
So I just opened http://xxx.xxx.xxx.xxx/ocpu like it worked on my other server. This time my browser doesn't show the OpenCPU API Explorer, but the following message:
Failed to set rlimit. ENOSYS
In call:
rlimit_wrapper("rlimit_as", hardlim, softlim, pid, verbose)
The server only has 1GB of physical memory, so I thought changing the "rlimit.as" to 1e9 instead of the standrd 2e9 would fix the problem (I also tried 750000000 and 500000000), but nothing helped (of course I restarted the service opencpu again after each change).
I also think that this is not the problem, because I guess the server would use virtual memory when an operation uses more than one GB.
I think the problem has to do with RAppArmor. So I tried to disable it and restart opencpu, but the problem didn't vanish:
$ sudo aa-disable usr.bin.r
Disabling /etc/apparmor.d/usr.bin.r.
Traceback (most recent call last):
File "/usr/sbin/aa-disable", line 30, in
tool.cmd_disable()
File "/usr/lib/python3/dist-packages/apparmor/tools.py", line 148, in cmd_disable
raise apparmor.AppArmorException(cmd_info[1])
apparmor.common.AppArmorException: 'Warning: unable to find a suitable fs in /proc/mounts, is it mounted?\nUse --subdomainfs to override.\n'
So does anyone know what the problem here could be or has any suggestions where to look for a solution (I tried to google already, but didn't find anything helpful)?
I don't think anything of the following is the cause of the problem, but since I'm not sure, I add these warnings anyways:
The only strange thing I encountered during the OpenCPU installation was this message (which appeared 4 times):
iptables v1.4.21: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
But afterwards it said:
* Reloading nginx configuration nginx [ OK ]
OK
Setting up opencpu (1.4.4-trusty15) ...
Also when I tried to install RAppArmor separately, I got the following warning:
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "UTF-8",
LANG = (unset)
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Selecting previously unselected package r-cran-rapparmor.
And also this one:
Warning: unable to find a suitable fs in /proc/mounts, is it mounted?\nUse --subdomainfs to override.\n
Thanks in advance!
It looks like your new hosting provider uses some sort of virtualization system that has a shared kernel which limits all kind of linux functionality, including rlimit, iptables and probably apparmor. Is an actual cloud host, or something you setup yourself?
It would be helpful to debug this in R (outside of opencpu). On your server, start R in the console and type:
library(RAppArmor, lib="/usr/lib/opencpu/library")
rlimit_as(1e9)
rlimit_fsize(1e9)
rlimit_cpu(1e5)
Using the following for just connection pooling no master_slave or replication: rhel 6, postgresql 9.1.9, & pgpool-II 3.1.3 (also tried 3.2.5)
Followed solution suggested in http://www.pgpool.net/pipermail/pgpool-general/2013-May/001773.html
After following the instructions for MD5 I also tried setting both pg_hba.conf and pool_hba.conf to trust for local and subnet, but still get the following error when attempting to connect to the pool locally:
ERROR: "MD5" authentication with pgpool failed for user foo
Tried locally on Fedora 18 with pg9.2 and pgpool from Fedora repo and worked right out of the box.
At the end of all routes suggested everywhere I could find.
Help would be greatly appreciated.
After having hit the same problem the solution was to change ownership of the pool_passwd file to postgres.
Even though this file has a 644 permission, if owner isn't postgres you'll always get the aforementioned error. I guess this file's owner and the user running pgpool must match.
I'm running PosgreSQL 9.2 and pgpool-II 3.3.2, BTW.