I had a look at the old thread where a problem was reported related to libjansi, too.
Rechecking it based on the message it indeed is different - I am sorry for that.
Nevertheless while in the old thread libjansi ( copy ) resp. it’s lock file couldn’t be created. The error message was about the lock file while this time it is about the lib.
Looking into the /var/lib/openhab/tmp folder during runtime of “openhab-cli console” a copy of libjansi should be created in the folder and the lock file.
Do you see these files ?
Running “ps -ef | grep jansi” you should see the path where libjansi is taken from ( source of copy ).
Is that the case ?
When I converted from OH 3.4 to 4.0 I’ve decided to give HTTP binding a try (I was using SmartHome/J HTTP Binding). But HTTP binding does not support special characters (that is the reason why I was using SmartHome/J HTTP Binding in 3.4). The error message is Requesting 'https://api.telegram.org/bot****************/sendMessage?chat_id=5003595502&text=Alerta%20-%20O%20videoporteiro%20não%20está%20registado' (method='GET', content='null') failed: 400 Bad Request
Do I need to return to SmartHome/J HTTP Binding ? How ? I can wait for HTTP binding to be updated.
Looking into the /var/lib/openhab/tmp folder during runtime of “openhab-cli console” a copy of libjansi should be created in the folder and the lock file.
Do you see these files ?
yes
openhabian@openhabian:/var/lib/openhab/tmp $ ls -lsh | grep jansi
24K -rwxr--r-- 1 root root 22K May 6 11:01 jansi-2.4.0-6a213f869437973-libjansi.so
0 -rw-r--r-- 1 root root 0 May 6 11:01 jansi-2.4.0-6a213f869437973-libjansi.so.lck
Here is the output of the ps command, I’m not sure I fully understand what you mean.
Running “ps -ef | grep jansi” you should see the path where libjansi is taken from ( source of copy ).
Is that the case ?
I have found the work around in Cody’s post here does NOT survive a restart of the host computer. Since you said:
I’m guessing you restart and the setting in the above post are lost and same thing happens. I’ve found that if I reset the safeCall to 100, openHAB runs for weeks without running away. Typical CPU usage is in the single digits.
When it pins the CPU, follow Cody’s advise in this post above and run top in the terminal, get the pid of openHAB then run
top -H -p <pid of openHAB >
with the pid you got from top where it says pid of openHAB above
Anyhow, having to log into the openHAB console and running the commands every time you restart the host is a pain. Cody mentioned that you could probably write a rule to reset the safeCall setting on a restart automatically but I don’t know how.
I also think this is ah… kind of a kludge
Curious @ML1982 do you run jRuby rules? What rules languages do you use?
Is this a problem with jRuby or openHAB in general? Anyone feel like explaining to me
@ML1982@Andrew_Rowe If your setups contain a lot of items and you have default persistence configured (or persistence for a lot of items), you are probably experiencing an issue recently found in th implementation of nearly all persistence services. This is already fixed for MapDB and InfluxDB in recent snapshots and a fix for RRD is on the way.
I’m guessing you restart and the setting in the above post are lost and same thing happens. I’ve found that if I reset the safeCall to 100, openHAB runs for weeks without running away. Typical CPU usage is in the single digits.
Have a look at this file.
/var/lib/openhab/etc/services.cfg
You can change the parameters of the workaround there and it will survive a reboot.
Is this a problem with jRuby or openHAB in general? Anyone feel like explaining to me
No, I had the problem before I installed ruby today. I only installed ruby because of the advice in the workaround.
I only use ECMA2021 scripts.
Openhab just restarted after 4 hours… the workaround doesn’t work for me.
I have three startup errors that may be related to the “CPU usage and restart bug”.
Ignoring invalid configuration for pool 'felix.fileinstall.filename': file:/var/lib/openhab/etc/org.openhab.threadpool.cfg - value must be an integer
The transformation add-on 'javascript' does not exist - ignoring it.
I’ve have to restart this bundles after each restart of OH manually:
Thanks for the hint
Mine was located at /usr/share/openhab/runtime/services.cfg
I’m going to leave it be and try removing RRD
I’ve been doing some firmware development on esp8266 and every once in awhile the com port go sideways and the only way to bring it back is to restart
this issue made that kind of a PITA
I am already using influxDB, the persistence setup is
Strategies {
everyMinute : "0 * * * * ?"
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
every2Minutes : "0 */2 * ? * *"
// if no strategy is specified for an Item entry below, the default list will be used
default = everyUpdate
}
Items {
// persist the Item state of Heating_Mode and Notifications_Active on every change and restore them from the db at startup
* : strategy = everyUpdate, everyMinute
gRestoreOnStartup* : strategy = restoreOnStartup
// additionally, persist all temperature and weather values every hour
//Temperature*, Weather* : strategy = everyHour
}
I’ve got 636 items and persistence for all of them. I think 636 is “a lot”.
Did I understand correctly that a bugfix is in recent snapshots but not yet in 4.0M2?
I recently disabled the Samsung bundle via karaf. I also reduced the number of lines in fronttail from 2000 to 200. At the moment the system seems to be stable. I will check again tomorrow morning.
About the other bug:
Ignoring invalid configuration for pool 'felix.fileinstall.filename': file:/var/lib/openhab/etc/org.openhab.threadpool.cfg - value must be an integer
The system remained stable throughout the night.
Now, after enabling the Samsung TV Binding, the OH web interface became slower, CPU usage increased and an hour later I had an automatic reboot of OH.
Ignoring invalid configuration for pool 'felix.fileinstall.filename': file:/var/lib/openhab/etc/org.openhab.threadpool.cfg - value must be an integer
is still there.
and this one, after starting openhab-cli console
openhabian@openhabian:~ $ sudo openhab-cli console
[sudo] password for openhabian:
Logging in as openhab
Password:
Failed to load native library:jansi-2.4.0-43230a45d4ce9e45-libjansi.so. osinfo: Linux/arm
java.lang.UnsatisfiedLinkError: /var/lib/openhab/tmp/jansi-2.4.0-43230a45d4ce9e45-libjansi.so: /var/lib/openhab/tmp/jansi-2.4.0-43230a45d4ce9e45-libjansi.so: cannot open shared object file: No such file or directory
I gather that from the thread that, for JSR223 Javascript rules (in .js files), Java 17 needs to be installed in OH4 (or the Nashorn addon). Will the rules then continue working without further changes, or are there other migration steps?
Regarding what to to with JavaScript rules, the Milestone 1 announcement (openHAB 4.0 Milestone Builds) gives some tips. For JSR223 JavaScript rules in /automation/jsr223, I think installing the Nashorn add-on should be enough, but you should probably migrate to JS Scripting (/automation/js) to use it‘s great helper library.