java.lang.NegativeArraySizeException

On starting weblogic on Solaris 10, I got this error

Could not load the performance pack that can take advantage of /dev/(e)poll device due to:
java.lang.NegativeArraySizeException.

I checked ulimit:

ulimit -n
65536

I reduced ulimit to 65534:

ulimit -n 65534

and weblogic started up fine.

I remember reading somewhere that java has array overflow issues if ulimit is set to maximum.

A connection to the server could not be established: null (user=DBA.ADMIN)

This morning I got a call from various people complaining about OTM not allowing them to login. Anyone who tried logging in got this error:

A connection to the server could not be established: null (user=any_valid_otm_user)

I checked $GLOG_HOME/logs/weblogic/console.log.0:


INFO | 2011/12/14 09:40:07 | -- OTM Event: serverReady
INFO | 2011/12/14 09:47:01 | javax.management.MBeanException: MBean invoke failed: weblogic.management.mbeanservers.edit.EditTimedOutException:
INFO | 2011/12/14 09:47:01 |
INFO | 2011/12/14 09:47:01 | javax.management.MBeanException: MBean invoke failed: weblogic.management.mbeanservers.edit.EditTimedOutException:
INFO | 2011/12/14 09:47:01 | at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:205)
INFO | 2011/12/14 09:47:01 | at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:222)
INFO | 2011/12/14 09:47:01 | at javax.management.remote.rmi.RMIConnectionImpl_1033_WLStub.invoke(Unknown Source)
INFO | 2011/12/14 09:47:01 | at weblogic.management.remote.common.RMIConnectionWrapper$16.run(ClientProviderBase.java:876)
INFO | 2011/12/14 09:47:01 | at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
INFO | 2011/12/14 09:47:01 | at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
INFO | 2011/12/14 09:47:01 | at weblogic.security.Security.runAs(Security.java:61)
INFO | 2011/12/14 09:47:01 | at weblogic.management.remote.common.RMIConnectionWrapper.invoke(ClientProviderBase.java:874)
INFO | 2011/12/14 09:47:01 | at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:993)
INFO | 2011/12/14 09:47:01 | at glog.util.jmx.JMXConnection.call(JMXConnection.java:104)
INFO | 2011/12/14 09:47:01 | at glog.util.j2ee.remote.WLManagementHelper$Edit.(WLManagementHelper.java:54)
INFO | 2011/12/14 09:47:01 | at glog.util.j2ee.jdbc.WLConnectionPoolInstance.create(WLConnectionPoolInstance.java:139)
INFO | 2011/12/14 09:47:01 | at glog.util.j2ee.jdbc.ASConnectionPoolInstance.(ASConnectionPoolInstance.java:52)
INFO | 2011/12/14 09:47:01 | at glog.util.datasource.AppServerConnectionPoolInstance.(AppServerConnectionPoolInstance.java:9)
INFO | 2011/12/14 09:47:01 | at glog.util.datasource.AppServerConnectionPool.getNewInstance(AppServerConnectionPool.java:71)
INFO | 2011/12/14 09:47:01 | at glog.util.datasource.AppServerConnectionPool.getInstance(AppServerConnectionPool.java:61)
INFO | 2011/12/14 09:47:01 | at glog.util.datasource.AppServerConnectionPool.reserve(AppServerConnectionPool.java:34)
INFO | 2011/12/14 09:47:01 | at glog.util.datasource.DataSource.reserve(DataSource.java:143)
INFO | 2011/12/14 09:47:01 | at glog.util.datasource.DataSource.reserve(DataSource.java:137)
INFO | 2011/12/14 09:47:01 | at glog.util.jdbc.noserver.T2SharedConnection$ReferencedConnection.addRef(T2SharedConnection.java:301)
INFO | 2011/12/14 09:47:01 | at glog.util.jdbc.noserver.T2SharedConnection$ReferencedConnection.addRef(T2SharedConnection.java:291)
INFO | 2011/12/14 09:47:01 | at glog.util.jdbc.noserver.T2SharedConnection.open(T2SharedConnection.java:57)
INFO | 2011/12/14 09:47:01 | at glog.server.useraccess.UserAccessSessionBean.getUserAccess(UserAccessSessionBean.java:154)
INFO | 2011/12/14 09:47:01 | at glog.server.useraccess.UserAccessSessionServerSideEJBWrapper.getUserAccess(UserAccessSessionServerSideEJBWrapper.java:87)
INFO | 2011/12/14 09:47:01 | at glog.server.useraccess.UserAccessSessionHome_uzvgzz_EOImpl.getUserAccess(UserAccessSessionHome_uzvgzz_EOImpl.java:1600)
INFO | 2011/12/14 09:47:01 | at glog.server.useraccess.UserAccessSessionHome_uzvgzz_EOImpl_WLSkel.invoke(Unknown Source)
INFO | 2011/12/14 09:47:01 | at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
INFO | 2011/12/14 09:47:01 | at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
INFO | 2011/12/14 09:47:01 | at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
INFO | 2011/12/14 09:47:01 | at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
INFO | 2011/12/14 09:47:01 | at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
INFO | 2011/12/14 09:47:01 | at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
INFO | 2011/12/14 09:47:01 | at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
INFO | 2011/12/14 09:47:01 | at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
INFO | 2011/12/14 09:47:01 | at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

I googled and found a few hits and in one of them found this line:

When I'm trying to deploy my project on weblogic I've got this error:
2007-02-09 16:05:15 CET Error Deployer BEA-149181 Deployment Service encountered error while aborting the edit session before start. Initiato
r for this edit session is 'principals=[kernel identity = -1632281053]'. Error is 'weblogic.management.provider.EditNotEditorException: Not edit lock
owner'
weblogic.management.provider.EditNotEditorException: Not edit lock owner

On seeing those words: Not edit lock owner, I realized that the previous day, I was trying to create SFTP File control in OTM Weblogic console. It wasn't letting me create a new one, till I clicked Lock and Edit. So I quickly logged into weblogic console and clicked on Release Configuration button. The subsequent logins to OTM started working after this.

passwordless ssh doesn't work

On both source and target servers ensure these permissions exist:

$ chmod go-w ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/id_rsa
$ chmod 644 ~/.ssh/id_rsa.pub
$ chmod 644 ~/.ssh/known_hosts

It didn't work for me in one case where $HOME directory had 777 permission

Looking at /var/log/auth.log on my server revealed the problem: sshd was
refusing to use my public key because my home directory was
group-writable. In order to do pubkey auth, both the home directory
and the .ssh directory must writable only by the owner.

Two parts: first, turn up debugging on your ssh sever. Edit /etc/ssh/sshd_config and increase LogLevel to DEBUG. Then force your ssh server to reload it's config with killall -HUP .

That will cause the server to add much more details to your /var/log/secure and/or /var/log/auth logfiles.

Secondly (actually you cant try this first), increase the debug level on the client side. ssh in to the box with

$ ssh -vvv hostname

and that will print out lots more info about where the process is failing.

If you do turn up the debug level on your ssh server, don't forget to turn it back down when you are finished.

A few more reasons why this fails:

1. Make sure the owner:group on the directories and files is correct:

ls -ld  $HOME/
ls -ld  $HOME/.ssh
ls -ltr $HOME/.ssh

Login as root

chown user:group $HOME
chown user:group $HOME/.ssh
chown user:group $HOME/.ssh/authorized_keys
chown user:group $HOME/.ssh/id_rsa
chown user:group $HOME/.ssh/id_rsa.pub
chown user:group $HOME/.ssh/known_hosts

2. This one took a lot of R&D.  The user's entry was missing in /etc/shadow

Login as root
grep user /etc/shadow

If user doesn't exist in /etc/shadow, ssh will fail.

This is caused, because unix admins sometimes do not use useradd command to add users, they just copy the line from /etc/passwd from an existing server and paste it in new server.  They forget to add the line for the user inside /etc/shadow.  If useradd command is used, it takes care of this automatically.