How to write log message with trace command in tcl? - tcl

So I have these sample code:
package require logger
set logger [logger::init someservice]
proc second {} {}
proc first {} {second}
${logger}::trace on
${logger}::trace add first second
puts "monitored procesured are: [${logger}::trace status]"
first
${logger}::delete
I got the following result after running the code :
[Wed Mar 14 11:44:11 EDT 2018] [someservice] [trace] 'enter {proc ::first
level 1 script {} caller {} procargs {}}'
[Wed Mar 14 11:44:11 EDT 2018] [someservice] [trace] 'enter {proc ::second
level 2 script {} caller ::first procargs {}}'
[Wed Mar 14 11:44:11 EDT 2018] [someservice] [trace] 'leave {proc ::second
level 2 script {} caller ::first status ok result {}}'
[Wed Mar 14 11:44:11 EDT 2018] [someservice] [trace] 'leave {proc ::first
level 1 script {} caller {} status ok result {}}'
I am trying to figure out how to use logger to write the result to a text file by setting up a filehandler. I tried to put "${::filehandler}" in the middle of the code, but it only printed out "first" in the text file. How should I type the command to print out the working process in another log file?

Consult the logger documentation, especially the section on logproc:
proc log2file {lvl txt} {
# handle output to file handle
}
set log [::logger::init example]
${log}::logproc trace log2file

Related

Google cloud compute engine freeze

Today I found out that my vm instance in the google cloud had an issue.
I could not connect via gcloud compute ssh. The only solution was to shut the vm down and restart it.
I guess I found the right log file where the error happened.
/var/log/daemon.log
Nov 23 17:39:01 globo-de systemd[1]: Started Clean php session files.
Nov 23 18:09:01 globo-de systemd[1]: Starting Clean php session files...
Nov 23 18:09:03 globo-de systemd[1]: Started Clean php session files.
Nov 23 18:39:01 globo-de systemd[1]: Starting Clean php session files...
Nov 23 18:39:04 globo-de systemd[1]: Started Clean php session files.
Nov 23 18:56:49 globo-de google-ip-forwarding: WARNING Exception running ['ip', 'route', 'ls', 'table', 'local', 'type', 'local', 'scope', 'host', 'dev', 'eth0', 'proto', '66']. [Errno 12] Cannot allocate memory.
Nov 23 18:57:43 globo-de google-accounts: ERROR Exception calling the response handler. [Errno 12] Cannot allocate memory.#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/metadata_watcher.py", line 196, in WatchMetadata#012 handler(response)#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/accounts_daemon.py", line 259, in HandleAccounts#012 self.oslogin.UpdateOsLogin(enable=False)#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 79, in UpdateOsLogin#012 status = self._GetStatus()#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 60, in _GetStatus#012 retcode = self._RunOsLoginControl('status')#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 47, in _RunOsLoginControl#012 return subprocess.call([constants.OSLOGIN_CONTROL_SCRIPT, action])#012 File "/usr/lib/python2.7/subprocess.py", line 168, in call#012 return Popen(*popenargs, **kwargs).wait()#012 File "/usr/lib/python2.7/subprocess.py", line 390, in __init__#012 errread, errwrite)#012 File "/usr/lib/python2.7/subprocess.py", line 916, in _execute_child#012 self.pid = os.fork()#012OSError: [Errno 12] Cannot allocate memory
Nov 23 18:58:02 globo-de google-ip-forwarding: WARNING Exception running ['ip', 'route', 'ls', 'table', 'local', 'type', 'local', 'scope', 'host', 'dev', 'eth0', 'proto', '66']. [Errno 12] Cannot allocate memory.
Nov 23 18:59:35 globo-de google-ip-forwarding: WARNING Exception running ['ip', 'route', 'ls', 'table', 'local', 'type', 'local', 'scope', 'host', 'dev', 'eth0', 'proto', '66']. [Errno 12] Cannot allocate memory.
Nov 23 18:59:54 globo-de google-accounts: ERROR Exception calling the response handler. [Errno 12] Cannot allocate memory.#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/metadata_watcher.py", line 196, in WatchMetadata#012 handler(response)#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/accounts_daemon.py", line 259, in HandleAccounts#012 self.oslogin.UpdateOsLogin(enable=False)#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 79, in UpdateOsLogin#012 status = self._GetStatus()#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 60, in _GetStatus#012 retcode = self._RunOsLoginControl('status')#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 47, in _RunOsLoginControl#012 return subprocess.call([constants.OSLOGIN_CONTROL_SCRIPT, action])#012 File "/usr/lib/python2.7/subprocess.py", line 168, in call#012 return Popen(*popenargs, **kwargs).wait()#012 File "/usr/lib/python2.7/subprocess.py", line 390, in __init__#012 errread, errwrite)#012 File "/usr/lib/python2.7/subprocess.py", line 916, in _execute_child#012 self.pid = os.fork()#012OSError: [Errno 12] Cannot allocate memory
Nov 23 19:03:53 globo-de google-ip-forwarding: WARNING Exception running ['ip', 'route', 'ls', 'table', 'local', 'type', 'local', 'scope', 'host', 'dev', 'eth0', 'proto', '66']. [Errno 12] Cannot allocate memory.
Nov 23 19:07:52 globo-de google-accounts: ERROR Exception calling the response handler. [Errno 12] Cannot allocate memory.#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/metadata_watcher.py", line 196, in WatchMetadata#012 handler(response)#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/accounts_daemon.py", line 259, in HandleAccounts#012 self.oslogin.UpdateOsLogin(enable=False)#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 79, in UpdateOsLogin#012 status = self._GetStatus()#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 60, in _GetStatus#012 retcode = self._RunOsLoginControl('status')#012 File "/usr/lib/python2.7/dist-packages/google_compute_engine/accounts/oslogin_utils.py", line 47, in _RunOsLoginControl#012 return subprocess.call([constants.OSLOGIN_CONTROL_SCRIPT, action])#012 File "/usr/lib/python2.7/subprocess.py", line 168, in call#012 return Popen(*popenargs, **kwargs).wait()#012 File "/usr/lib/python2.7/subprocess.py", line 390, in __init__#012 errread, errwrite)#012 File "/usr/lib/python2.7/subprocess.py", line 916, in _execute_child#012 self.pid = os.fork()#012OSError: [Errno 12] Cannot allocate memory
Nov 23 19:09:37 globo-de google-ip-forwarding: WARNING Exception running ['ip', 'route', 'ls', 'table', 'local', 'type', 'local', 'scope', 'host', 'dev', 'eth0', 'proto', '66']. [Errno 12] Cannot allocate memory.
Nov 23 19:11:32 globo-de systemd[1]: phpsessionclean.service: Failed to fork: Cannot allocate memory
Nov 23 19:11:56 globo-de systemd[1]: phpsessionclean.service: Failed to run 'start' task: Cannot allocate memory
Nov 23 19:12:24 globo-de systemd[1]: Failed to start Clean php session files.
Nov 23 19:12:50 globo-de systemd[1]: phpsessionclean.service: Unit entered failed state.
Nov 23 19:13:37 globo-de systemd[1]: phpsessionclean.service: Failed with result 'resources'.
Nov 23 19:14:58 globo-de systemd[1]: apt-daily.service: Failed to fork: Cannot allocate memory
Nov 23 19:16:13 globo-de systemd[1]: apt-daily.service: Failed to run 'start' task: Cannot allocate memory
What can I do to prevent that from happening again?
I guess the problem was that the google-cloud-compute engine vm had no swap file. So I created one with the following commands I found on google.
sudo dd if=/dev/zero of=/var/swap bs=2048 count=524288
sudo chmod 600 /var/swap
sudo mkswap /var/swap
sudo swapon /var/swap
Then I added the following line to /etc/fstab to make it permanent.
/var/swap none swap sw 0 0
Another solution is to avoid swapping setting vm.swappiness to 0.
# sysctl -w vm.swappiness=0
However, it sounds me more like an OS image issue than google clouds.

Could not initialize corosync configuration API error 12

Unable to initialize corosync running inside a docker container. The corosync-cfgtool -s command yields the following:
Could not initialize corosync configuration API error 12
The /etc/corosync/corosync.conf file has the following:
compatibility: whitetank
totem {
version: 2
secauth: off
threads: 0
interface {
ringnumber: 0
bindnetaddr: 127.0.0.1
mcastaddr: 239.255.1.1
mcastport: 5405
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: yes
logfile: /var/log/corosync.log
to_syslog: yes
debug: off
timestamp: on
logger_subsys {
subsys: AMF
debug: off
}
}
The /var/log/corosync.log file shows the following:
May 02 20:13:22 corosync [MAIN ] Could not set SCHED_RR at priority 99: Operation not permitted (1)
May 02 20:13:22 corosync [MAIN ] Could not lock memory of service to avoid page faults: Cannot allocate memory (12)
May 02 20:13:22 corosync [MAIN ] Corosync Cluster Engine ('1.4.6'): started and ready to provide service.
May 02 20:13:22 corosync [MAIN ] Corosync built-in features: nss
May 02 20:13:22 corosync [MAIN ] Successfully read main configuration file '/etc/corosync/corosync.conf'.
May 02 20:13:22 corosync [TOTEM ] Initializing transport (UDP/IP Multicast).
May 02 20:13:22 corosync [TOTEM ] Initializing transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0).
I was running the following in a bash script:
service corosync start
service corosync status
corosync-cfgtool -s
Apparently it was running too quickly and not giving corosync enough time to initialize. Changing the script to the following seems to have worked:
service corosync start
service corosync status
sleep 5
corosync-cfgtool -s
I now see the following output from corosync-cfgtool -s:
Printing ring status.
Local node ID 16777343
RING ID 0
id = 127.0.0.1
status = ring 0 active with no faults

WebSphere Liberty Profile blocking on Datasource lookup

I'm trying to configure a datasource in IBM WebSphere Liberty Profile (16.0.0.3) and this is what I've done so far:
server.xml
<authData id="dbuser" password="{xor}blablabla" user="MY_USER"/>
<dataSource id="Oracle" isolationLevel="TRANSACTION_READ_COMMITTED"
jdbcDriverRef="OracleDriver"
jndiName="EPMS_DS"
recoveryAuthDataRef="dbuser"
type="javax.sql.ConnectionPoolDataSource">
<properties.oracle databaseName="DBNAME" portNumber="1521" serverName="SERVERNAME"/>
</dataSource>
<jdbcDriver id="OracleDriver"
javax.sql.ConnectionPoolDataSource="oracle.jdbc.pool.OracleConnectionPoolDataSource"
libraryRef="shared-library"/>
web.xml
<resource-env-ref>
<description>The Oracle DS</description>
<resource-env-ref-name>jdbc/OracleDS</resource-env-ref-name>
<resource-env-ref-type>javax.sql.DataSource</resource-env-ref-type>
</resource-env-ref>
ibm-web-bnd.xml
<resource-ref name="jdbc/OracleDS" binding-name="EPMS_DS">
<authentication-alias name="dbuser" />
</resource-ref>
However, besides the application server is taking more than 2 minutes to startup, my application seems to freeze on the following instruction:
ctx = new InitialContext();
ctx.lookup("java:comp/env/jdbc/OracleDS");
The log doesn't show any errors, the last line it shows is an application's debug message indicating it is going to do a JNDI lookup.
I've also tried different configurations in server.xml, without <authData> and explicitly defining user and password on the datasource, but with identical results:
<dataSource id="Oracle" isolationLevel="TRANSACTION_READ_COMMITTED" jdbcDriverRef="OracleDriver" jndiName="EPMS_DS" type="javax.sql.ConnectionPoolDataSource">
<properties.oracle URL="jdbc:oracle:thin:#SERVERNAME:1521:DBNAME" password="{xor}blablabla" user="MY_USER"/>
</dataSource>
Sadly, Liberty Profile doesn't seem to provide a way to test the DB connection, but everything seems correctly configured (I can assure the credentials are correct, as well as the server name and port). What am I missing here?
EDIT #1
Following njr's suggestion, I've performed a thread dump and here is a summary:
- waiting on com.ibm.tx.jta.impl.EventSemaphore#737eaefc
- waiting on com.ibm.ws.objectManager.FileLogOutput$FlushHelper#19d51071
- waiting on com.ibm.ws.objectManager.FileLogOutput$NotifyHelper#2fa0da91
- waiting on com.ibm.ws.objectManager.ObjectManagerState$CheckpointHelper#5b0919fc
- waiting on com.ibm.ws.sib.msgstore.persistence.dispatcher.SpillDispatcher$DispatchingLock#1620db94
(8 Occorrences, but different instances)
...
- waiting on com.ibm.ws.threading.internal.BoundedBuffer$GetQueueLock#c8a05b6
(56 Occorrences, but different instances)
...
- waiting on java.lang.Object#4c1d5897
- waiting on java.lang.ref.Reference$Lock#5448da4c
- waiting on java.lang.ref.ReferenceQueue$Lock#f91b025
- waiting on java.util.LinkedList#5b213416
- waiting on java.util.LinkedList#6cb46e1f
- waiting on java.util.TaskQueue#f50561c
(14 Occorrences, but different instances)
...
- waiting on java.util.concurrent.atomic.AtomicReference#5476d077
- waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#4da17c93
- waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#513339c6
- waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#5dc2ae0f
- waiting on org.eclipse.osgi.framework.eventmgr.EventManager$EventThread#236970be
- waiting on org.eclipse.osgi.framework.eventmgr.EventManager$EventThread#6dfdd5
- waiting on org.eclipse.osgi.framework.eventmgr.EventManager$EventThread#72ce4e1c
- blocked on com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper#5748c911
- blocked on com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper#5748c911
Can someone help me to interpret this?
EDIT #2
Here's where the complete stack trace of the blocked threads:
LargeThreadPool-thread-148 [217] (BLOCKED)
com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper.start line: 63
com.ibm.tx.jta.util.TxTMHelper.start line: 461
com.ibm.tx.util.TMHelper.start line: 74
com.ibm.tx.jta.util.TxTMHelper.checkTMState line: 500
com.ibm.tx.util.TMHelper.checkTMState line: 116
com.ibm.tx.jta.impl.TranManagerSet.registerResourceInfo line: 270
com.ibm.ws.transaction.services.TransactionManagerService.registerResourceInfo line: 260
com.ibm.ejs.j2c.ConnectionManager.registerXAResourceInfo line: 2537
com.ibm.ejs.j2c.ConnectionManager.<init> line: 509
com.ibm.ejs.j2c.ConnectionManagerServiceImpl.getConnectionManager line: 407
com.ibm.ejs.j2c.ConnectionManagerServiceImpl.getConnectionManager line: 54
com.ibm.ws.jca.cm.AbstractConnectionFactoryService.createResource line: 146
com.ibm.ws.injectionengine.osgi.internal.IndirectJndiLookupObjectFactory.createResourceWithFilter line: 346
com.ibm.ws.injectionengine.osgi.internal.IndirectJndiLookupObjectFactory.createResource line: 319
com.ibm.ws.injectionengine.osgi.internal.IndirectJndiLookupObjectFactory.getObjectInstance line: 133
com.ibm.ws.injectionengine.osgi.internal.IndirectJndiLookupObjectFactory.getObjectInstance line: 99
com.ibm.wsspi.injectionengine.InjectionBinding.getInjectionObjectInstance line: 1556
com.ibm.wsspi.injectionengine.InjectionBinding.getInjectionObject line: 1433
com.ibm.wsspi.injectionengine.InjectionBinding.getInjectionObject line: 1389
com.ibm.ws.injectionengine.osgi.internal.naming.InjectionJavaColonHelper.getObjectInstance line: 116
com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLContext.lookup line: 333
com.ibm.ws.jndi.url.contexts.javacolon.internal.JavaURLContext.lookup line: 371
org.apache.aries.jndi.DelegateContext.lookup line: 161
javax.naming.InitialContext.lookup line: 417
pt.sibs.epms.persistence.utils.EntityManagerFactoryController.jndiLookupUsed line: 264
pt.sibs.epms.persistence.utils.EntityManagerFactoryController.checkConfiguration line: 115
pt.sibs.epms.persistence.utils.EntityManagerFactoryController.<init> line: 95
pt.sibs.epms.persistence.utils.EntityManagerFactoryController.<init> line: 51
pt.sibs.epms.persistence.utils.EntityManagerFactoryController$SingletonHolder.<clinit> line: 81
pt.sibs.epms.persistence.utils.EntityManagerFactoryController.getInstance line: 88
pt.sibs.epms.util.logging.LoggerConfiguration.<clinit> line: 33
pt.sibs.epms.ecc.renderer.HtmlFormRenderer.<clinit> line: 25
java.lang.Class.forName0 line: not available [native method]
java.lang.Class.forName line: 348
com.ibm.ws.webcontainer.osgi.webapp.WebApp.addClassToHandlesTypesStartupSet line: 1104
com.ibm.ws.webcontainer.osgi.webapp.WebApp.scanForHandlesTypesClasses line: 1038
com.ibm.ws.webcontainer.webapp.WebApp.initializeServletContainerInitializers line: 2493
com.ibm.ws.webcontainer.webapp.WebApp.initialize line: 1037
com.ibm.ws.webcontainer.webapp.WebApp.initialize line: 6545
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApp line: 466
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.createRunnableHandler line: 264
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.createRunnableHandler line: 329
com.ibm.ws.http.internal.VirtualHostImpl.discriminate line: 251
com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready line: 301
com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination line: 471
com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest line: 405
com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest line: 285
com.ibm.ws.http.channel.internal.inbound.HttpICLReadCallback.complete line: 66
com.ibm.ws.channel.ssl.internal.SSLReadServiceContext$SSLReadCompletedCallback.complete line: 1777
com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete line: 504
com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO line: 574
com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun line: 929
com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run line: 1018
java.util.concurrent.ThreadPoolExecutor.runWorker line: 1142
java.util.concurrent.ThreadPoolExecutor$Worker.run line: 617
java.lang.Thread.run line: 745
And the second thread:
LargeThreadPool-thread-3 [33] (BLOCKED)
com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper.start line: 63
com.ibm.tx.jta.util.TxTMHelper.start line: 461
com.ibm.tx.util.TMHelper.start line: 74
com.ibm.tx.jta.util.TxTMHelper.checkTMState line: 500
com.ibm.tx.util.TMHelper.checkTMState line: 116
com.ibm.tx.jta.impl.TranManagerSet.begin line: 167
com.ibm.ejs.csi.TranStrategy.beginGlobalTx line: 593
com.ibm.ejs.csi.Required.preInvoke line: 56
com.ibm.ejs.csi.TransactionControlImpl.preInvoke line: 222
com.ibm.ejs.container.EJSContainer.preInvokeActivate line: 3176
com.ibm.ejs.container.EJSContainer.EjbPreInvoke line: 2576
com.ibm.ejs.container.TimedObjectWrapper.invokeCallback line: 84
com.ibm.ejs.container.TimerNpRunnable.doWork line: 196
com.ibm.ejs.container.TimerNpRunnable.run line: 103
java.util.concurrent.Executors$RunnableAdapter.call line: 511
java.util.concurrent.FutureTask.run line: 266
java.util.concurrent.ThreadPoolExecutor.runWorker line: 1142
java.util.concurrent.ThreadPoolExecutor$Worker.run line: 617
java.lang.Thread.run line: 745
Edit #3
The thread that is WAITING and, apparently, blocking the other two threads:
LargeThreadPool-thread-38 [103] (WAITING)
java.lang.Object.wait line: not available [native method]
java.lang.Object.wait line: 502
com.ibm.tx.jta.impl.EventSemaphore.waitEvent line: 71
com.ibm.tx.jta.impl.RecoveryManager.waitForReplayCompletion line: 1273
com.ibm.tx.jta.impl.TxRecoveryAgentImpl.initiateRecovery line: 413
com.ibm.ws.recoverylog.spi.RecoveryDirectorImpl.directInitialization line: 751
com.ibm.ws.recoverylog.spi.RecoveryDirectorImpl.driveLocalRecovery line: 1240
com.ibm.ws.recoverylog.spi.RecLogServiceImpl.start line: 125
com.ibm.tx.jta.embeddable.impl.EmbeddableTMHelper.start line: 130
com.ibm.tx.jta.util.TxTMHelper.start line: 461
com.ibm.tx.util.TMHelper.start line: 74
com.ibm.tx.jta.util.TxTMHelper.checkTMState line: 500
com.ibm.tx.util.TMHelper.checkTMState line: 116
com.ibm.tx.jta.impl.TranManagerSet.begin line: 167
com.ibm.ws.transaction.services.TransactionManagerService.begin line: 281
com.ibm.ws.concurrent.persistent.internal.PersistentExecutorImpl$PollingTask.run line: 2239
Not sure if it is related, but ffdc is showing the following exception:
------Start of DE processing------ = [09-11-2016 14:41:09:006 GMT]
Exception = com.ibm.ws.recoverylog.spi.LogIncompatibleException
Source = com.ibm.ws.recoverylog.spi.LogHandle
probeid = 326
Stack Dump = com.ibm.ws.recoverylog.spi.LogIncompatibleException
at com.ibm.ws.recoverylog.spi.LogFileHandle.fileOpen(LogFileHandle.java:522)
at com.ibm.ws.recoverylog.spi.LogHandle.openLog(LogHandle.java:324)
at com.ibm.ws.recoverylog.spi.MultiScopeRecoveryLog.openLog(MultiScopeRecoveryLog.java:602)at com.ibm.ws.recoverylog.spi.RecoveryLogImpl.openLog(RecoveryLogImpl.java:77)
at com.ibm.tx.jta.impl.RecoveryManager.run(RecoveryManager.java:1835)
at java.lang.Thread.run(Thread.java:745)
In your Edit #3, the thread that is waiting in
com.ibm.tx.jta.impl.RecoveryManager.waitForReplayCompletion
will have spawned another recoveryManager thread who's role is to access the transaction log files in your flesystem. That other thread Should do the minimal amount of file processing necessary before signalling to the waiting thread that it may continue. Can you see another thread with a stack containing
com.ibm.tx.jta.impl.RecoveryManager.run ?
I am concerned about the LogIncompatibleException. It suggests that the transaction log files on your filesystem are
corrupt. This should not cause the server to hang and I believe you've hit a product defect.
If you need to make progress quickly, it may be appropriate in your scenario to delete the transaction log files.
Please note that this is something we only suggest to customers with extreme care as the transaction logs ensure
the integrity of distributed transactions. In a production environment we'd generally recommend that such action
is only taken under the guidance of IBM Level 3 Service. But in a test/evaluation scenario it can be applicable.
The Liberty transaction log info is stored in the /wlp/usr/servers//tranlog
directory. If appropriate the tranlog and partnerlog subdirectories may be deleted and the server restarted.

Core OWASP ModSecurity - Allowing JSON

I've had ModSecurity and the Core OWASP Rule Set ver.2.2.5 installed for some months now, but a JSON endpoint on the site has recently stopped responding, and the Apache log gets the following:
[Tue Jul 21 10:41:12 2015] [error] [client 194.54.11.146] ModSecurity:
Warning. Match of "streq %{SESSION.IP_HASH}" against "TX:ip_hash"
required. [file
"/etc/modsecurity/activated_rules/modsecurity_crs_16_session_hijacking.conf"]
[line "35"] [id "981059"] [msg "Warning - Sticky SessionID Data
Changed - IP Address Mismatch."] [hostname "************"] [uri
"/api/campaigns/d3c735cb-0773-11e4-98bd-02f651afdab5"] [unique_id
"Va4hyKwfKiYAAAYSLigAAAAJ"]
[Tue Jul 21 10:41:12 2015] [error] [client 194.54.11.146] ModSecurity:
Warning. Match of "streq %{SESSION.UA_HASH}" against "TX:ua_hash"
required. [file
"/etc/modsecurity/activated_rules/modsecurity_crs_16_session_hijacking.conf"]
[line "36"] [id "981060"] [msg "Warning - Sticky SessionID Data
Changed - User-Agent Mismatch."] [hostname "************"] [uri
"/api/campaigns/d3c735cb-0773-11e4-98bd-02f651afdab5"] [unique_id
"Va4hyKwfKiYAAAYSLigAAAAJ"]
[Tue Jul 21 10:41:12 2015] [error] [client 194.54.11.146] ModSecurity:
Warning. Operator EQ matched 2 at TX:sticky_session_anomaly. [file
"/etc/modsecurity/activated_rules/modsecurity_crs_16_session_hijacking.conf"]
[line "37"] [id "981061"] [msg "Possible Session Hijacking - IP
Address and User-Agent Mismatch."] [hostname "************"] [uri
"/api/campaigns/d3c735cb-0773-11e4-98bd-02f651afdab5"] [unique_id
"Va4hyKwfKiYAAAYSLigAAAAJ"]
[Tue Jul 21 10:41:12 2015] [error] [client 194.54.11.146] ModSecurity:
Warning. Match of "rx ^%{tx.allowed_request_content_type}$" against
"TX:0" required. [file
"/etc/modsecurity/activated_rules/modsecurity_crs_30_http_policy.conf"]
[line "64"] [id "960010"] [msg "Request content type is not allowed by
policy"] [data "application/json"] [severity "WARNING"] [tag
"POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag
"OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"]
[hostname "************"] [uri
"/api/campaigns/d3c735cb-0773-11e4-98bd-02f651afdab5"] [unique_id
"Va4hyKwfKiYAAAYSLigAAAAJ"]
I'm new to mod_security and the OWASP rules (I basically followed the guide here) but as I understand, rules are scored, and if a request passes a threshold, it's nuked. I assume this is what I'm seeing here.
The final one is the one that concerns me - "application/json" should certainly be allowed. From looking at /etc/modsecurity/modsecurity_crs_10_setup.conf, I see:
setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/x-amf'
My question is:
1. Can I just add application/json in here to make the error go away?
2. Is that the correct way to do it?
Yes you can so it reads like this:
setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/x-amf|application/json'
Yes that is the correct way of doing this.

Vagrant Chef Recipe Checksum Calculations

I am running a mysql recipe that is failing. When I do vagrant up after a halt it claims that grants.sql template's checksum has changed causing it to re-run when it shouldn't.
[default] [Wed, 28 Mar 2012 12:58:48 -0700] INFO: Processing template[/etc/mysql/grants.sql] action create (mysql::server line 128)
: stdout
[default] [Wed, 28 Mar 2012 12:58:48 -0700] DEBUG: Current content's checksum: 3992e44304b56cebdbd4bf23183ddd78f877539c025227546e19098b0b5872ca
: stdout
[default] [Wed, 28 Mar 2012 12:58:48 -0700] DEBUG: Rendered content's checksum: f967f212b3e7b25a08ed35d086938846c188f6e9980a1ecc42635136841587a4
: stdout
[default] [Wed, 28 Mar 2012 12:58:48 -0700] INFO: template[/etc/mysql/grants.sql] backed up to /var/chef/backup/etc/mysql/grants.sql.chef-20120328125848
: stdout
[default] [Wed, 28 Mar 2012 12:58:48 -0700] INFO: template[/etc/mysql/grants.sql] updated content
: stdout
[default] [Wed, 28 Mar 2012 12:58:48 -0700] INFO: template[/etc/mysql/grants.sql] sending run action to execute[mysql-install-privileges] (immediate)
: stdout
[default] [Wed, 28 Mar 2012 12:58:48 -0700] INFO: Processing execute[mysql-install-privileges] action run (mysql::server line 137)
: stdout
[default] [Wed, 28 Mar 2012 12:58:48 -0700] INFO: execute[mysql-install-privileges] sh(/usr/bin/mysql -u root -p"evanta" < /etc/mysql/grants.sql)
: stdout
[default] [Wed, 28 Mar 2012 12:58:48 -0700] ERROR: execute[mysql-install-privileges] (mysql::server line 137) has had an error
[Wed, 28 Mar 2012 12:58:48 -0700] ERROR: template[/etc/mysql/grants.sql] (/tmp/vagrant-chef-1/chef-solo-1/mysql/recipes/server.rb:128:in `rescue in from_file') had an error:
execute[mysql-install-privileges] (mysql::server line 137) had an error: Chef::Exceptions::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /usr/bin/mysql -u root -p"evanta" < /etc/mysql/grants.sql ----
STDOUT:
STDERR: ERROR 1396 (HY000) at line 12: Operation CREATE USER failed for 'root'#'%'
---- End output of /usr/bin/mysql -u root -p"evanta" < /etc/mysql/grants.sql ----
Ran /usr/bin/mysql -u root -p"evanta" < /etc/mysql/grants.sql returned 1
Any ideas how these checksums are completed and how to fix this?
The best way to debug these issues is to take a look at the new file it created, in this case at /etc/mysql/grants.sql, and then to look at the backup at /var/chef/backup/etc/mysql/grants.sql.chef-20120328125848 (from the logs you posted). The backup is always made, so you can compare the contents of the two, and proceed to fix the Chef recipe to make sure it generates the same content.