Frequent unwanted reboots of openHAB on ODROID-XU4

@wborn Thanks for your advise - I have now pinned the java engine to the big cores. Still using knx V1 for now. Let’s see what happens during the next 24 hrs.

Thanks for your help :slight_smile:

1 Like

@wborn Running stable so far. Looks good. Pinning the java engine helped.
I wait another couple of days, then I plan to go back to knx V2

1 Like

I am running again on Ubuntu 18.04 LTS with OH 2.3 and knx V2.
I have pinned the java engine to the big cores.
Looks good and stable. I think we can close this case.
I am disappointed though about the poor HW, but that’s a different story.

Thanks @wborn @s.simma for helping!

1 Like

That’s very good news @boxerfahrer! :smiley:

There should at least have been a software fix for the default Java VM that’s part of the ODROID Ubuntu distribution. E.g. this CPU pinning approach or maybe compiling it with fewer optimizations as is suggested in the ODROID forum thread. A generic fix in the Linux kernel might be even better! :slight_smile:


I tried to follow these instructions, but got a warning about not having “Service lacks both ExecStart= and ExecStop= setting. Refusing.”

Can you shed any light on this?

(I’m not a programmer or coder, so I’m really out of my comfort zone)

Any assistance would be welcomed.



cpuset.service - Setup CPU groups
Loaded: error (Reason: Invalid argument)
Active: inactive (dead)
Aug 18 10:25:05 ODroid systemd[1]: [/etc/systemd/system/cpuset.service:10] Failed to parse service type, ignoring: oneshot ExecStart=/bin/true
Aug 18 10:25:05 ODroid systemd[1]: cpuset.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Aug 18 10:25:05 ODroid systemd[1]: cpuset.service: Cannot add dependency job, ignoring: Unit cpuset.service is not loaded properly: Invalid argument

I’ll reply here as you sent me a PM, that way others can find the info as well. I do not have an ARM with big little cores so I can not help, other than to pass on some links I came across…

User posted that they followed the guide in the Feb 2017 Odroid Mag (I think it is page 12 and this link will take you there)

The forum linked above is a conversation between the editor of the mag and an openhab user. Thankfully I found this info whilst trying to choose which ARM board to use, so I purchased the Odroid C2 instead and have a rock solid little setup now that has been running for over a week.

1 Like 1

Perhaps the magic scheduler is the root cause here? :smile:

The official 3.10 kernel comes with a “magic” scheduler from Samsung which knows the processor’s
true power,

Hi all

I’ve finally found the time and head space to try to pin the Java processes to the big core…

I followed the instructions to the letter and now I can see that the taskset -p result has changed from ff to f0 so I have to assume that it has worked.

taskset -pc <PID>
Is a little easier to understand

I’ll keep an eye on it and report back …

Thanks for all the assistance and guidance :smile:


I think I’ve found a much easier way to pin tasks to a particular range of CPU cores.

As part of following the various instructions, I saw a reference to the taskset utility.

The taskset command is part of the util-linux package and is available from

apt-get install util-linux

By entering the following commands, I could adjust which CPU cores any process and it’s children were using

pidof java
Then enter the returned PID into…

taskset -pca {PID}

For example

taskset -pca 1024

To set which CPU cores are to be used is simply a matter of adding the -c set string.

So to set the process (and it’s children) to cores 0 to 3 would be

taskset -pca 0-3 1024

Not being a programmer, I needed to experiment a little, but eventually discovered that if I added the following line into /usr/lib/systemd/system/openhab2.service

After the ExecStart line which starts Karaf

ExecStartPost=/usr/bin/taskset -pca 4-7 $MAINPID

OpenHab2’s Java process is pinned to whichever CPU cores I want, in this case 4-7 (which I think are the Big cores).

Assigning to 4-7 returns the same f0 from taskset -p {PID} as the more long winded instructions, so should I assume these are the Big cores?

For those of the same programming skills as I, please don’t forget to run the following commands

systemctl daemon-reload

systemctl restart openhab2

Dear all,

I had the same problem and found this thread. Digging further I stumbled over a different way to pin the process to cores 4 to 7:
Just add the line


to the


section of your openhab2.service file. Systemd will then take care of pinning the process to the named cores.

After restarting openhab using

systemctl daemon-reload
systemctl restart openhab2

you can check CPU binding in the /proc fileystem.

ps auxww | grep java

gives you all java processes on your system together with their pid (second column). In my case it is 6616 currently.


grep -i cpu /proc/6616/status

(replace 6616 by the PID you found for your java process) you should see the following output:

Cpus_allowed:     f0
Cpus_allowed_list:        4-7

A process without CPU affinity would show

Cpus_allowed:     ff
Cpus_allowed_list:        0-7

instead, so if you still see that output something went wrong.

The process runs stable for more than 12 hours now, while it crashed every couple of minutes before, so CPU-pinning really brings a great improvement.

Hope that helps


1 Like

Short notice: updating to openhab 2.4 seems to overwrite the openhab2.service file, so afterwards you will have to add the setting again.




Thanks for the info and the update. Now you have had it running for a while, would you recommend the big.little range of arm processors with Openhab now you have used them for a while?
Recently Odroid released details of a new model, the N2 which also uses the big.little cores and it can be ordered with 4gb of ram which sounds great…

Considering one of those if they get good Kodi support, or if not the bigger H2 x86 based that could then double as a NAS and OH server in the one box using snapraid.

I see the odroid as a very good fit for openHAB, as it is powerful enough to run openHAB, influx (in my case) and grafana also for setups with a lot of items (about 300 in my config). I also have nextcloud running on the same box without any problem or computing power shortage. And you get all of this for less then 10W energy consumption (including the SSD drive). So I totally recommend that config.

1 Like

I’m now deploying the ODroid C2, which seems to be little more stable than the UX4.

The C2 only has big cores so doesn’t need any pinning.

My theory was that if I’m only running openHAB2 in the UX4 and having to pin it to the big cores, I might as well just use a machine that only has big cores.

I haven’t moved my home (deliberately overloaded) openHAB2 configuration to a C2, it’s a task I’m not looking forward to.
The client’s I’ve given C2 units to haven’t reported any issues.

FYI, I sell Velbus hardware and give customers an SBC to keep the system time updated.
It’s then totally their choice as to which UI they run.

So far everyone seems very happy with openHAB2.

Here’s a small improvement to keep openhab from wiping out your changes in the openhab2.service file.

sudo systemctl edit openhab2.service

and put the modifications in that file. If you get an error about ‘edit’ command not beeing known. Then create the file /etc/systemd/system/openhab.service.d/override.conf yourself and reload daemon and restart. If you run systemctl status you see that it now uses a drop-in.

BTW: If you’re already on OH3 change openhab2.service to openhab.service but the rest stays the same. Unfortunately a change of the service file name (which normally doesn’t happen) will not prevent you from loosing the drop-in file as well.