/etc/openhab/linux.parameters

Setup, Configuration and Use Installation
1

linux.parameters is a convenient way of adding and overwriting environment settings such as

EXTRA_JAVA_OPTS="-Duser.timezone=Europe/Berlin -Xms1500m -Xmx3000m -XX:+ExitOnOutOfMemoryError"
OPENHAB_BACKUPS=/myBackupDirectory

because this file does not get overwritten by any upgrade procedure.

Manual start of openhab
During manual start of openhab this file gets called as follows

Manual start of openhab from command line:

openhab-cli start

this script calls

/usr/share/openhab/start.sh

which calls

/etc/profile.d/openhab.sh

which sets environment variables in the following order:

/etc/default/openhab
/etc/profile.d/openhab.sh 
/etc/openhab/linux.parameters

The sequence is clear and you can follow the whole precudure.

Starting openhab by daemon
What I am missing is, how linux.parameters gets started if openhab is started by daemon:

/etc/systemd/system/openhab.service

has its own set of variables and includes

/etc/default/openhab

and openhab ist started by this command:

/usr/share/openhab/runtime/bin/karaf

in this script and its include files I do not see any reference, that either

/etc/profile.d/openhab.sh
or
/etc/openhab/linux.parameters

is called.
However, I have proof, that the file linux.parameters gets executed because all my backups are stored correctly in the directory provided by linux.parameters.

Can anybody add the missing link how/where karaf script calls linux.parameters?

According to my information daemon files do not use environments of an interactive shell, in which case /etc/profile.d/openhab.sh would have been run.

your code goes here
2

Hi @Oliver2,

I’m assuming you’re creating your backups using openhab-cli backup [...]? openhab-cli is included with the apt or yum installation. It’s location is /usr/bin/openhab-cli and sources /etc/profile.d/openhab.sh which is why you get the linux.parameters version of the backup directory.

As far as I know, there is no karaf route in creating a backup.

Correct, we can prove this by editing linux.parameters and looking at the environment variables of a newly started service:

user@system:~ $ systemctl status openhab.service
â—Ź openhab.service - openHAB - empowering the smart home
   [...]
   Main PID: 742499 (java)
   [...]

user@system:~ $ sudo strings /proc/742499/environ

The variables which are only found in linux.parameters won’t appear. We should probably raise an issue for this, there is absolutely no reason to me why parameters set for the purposes of openHAB can’t be seen by openHAB.

3

Thanks Ben for your information.
The main reason behind this research is, that quite a few users had problems with the time zone within java (there are quite a few threads about this here). To solve this problem you could add

EXTRA_JAVA_OPTS="-Duser.timezone=Europe/Berlin"

to this file

/etc/default/openhab

but from time to time this file gets overwritten with default values, probably after updates.

So I think there should be a safe place to override settings to environment variables (like backup, heap memory, time zone, etc) and I thought it is linux.parameters but I seem to be wrong.

Do you know of a different place to store environment variables? Otherwise I’ll open a ticket.

Would you agree to add the following line

EnvironmentFile=-/etc/openhab/linux.parameters

to the service section of this file

/etc/systemd/system/openhab.service

?

EDIT:
I made a quick lookup on github and found out the older init daemon /etc/init.d/deb/openhab had linux.parameters included:

# Override configuration variables from user file if it present
if [ -r ${OPENHAB_CONF}/linux.parameters ]; then
  . ${OPENHAB_CONF}/linux.parameters
fi

Probably for certain reasons that was dropped in systemd. But makes sense to me to reinclude it again

4

Yes, the original intention of linux.parameters was to have a recommended file to add that is not managed by apt or yum.

I have a feeling that when it was originally added, it was primarily aimed at init.d systems. I can’t recall anyone asking about it for systemd services before.

We could add this to openhab.service as you suggest to match the same behavior as starting it manually.

However, generally if you want to have your own Environment vars for a systemd service without interference from the apt mechanism that set it up. You can use the following:

sudo systemctl edit openhab

This will allow you to override or add your own settings to openHAB’s service and the file that gets created isn’t tracked by apt or yum.

### Editing /etc/systemd/system/openhab.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
EnvironmentFile=-/etc/openhab/linux.parameters

So there’s two ways of going about it:

  1. We add the EnvironmentFile parameter to /etc/systemd/system/openhab.service, this may have consequences to anyone who has a legacy linux.parameters file in their system but I think there chance of this is very low and acceptable considering anyone editing this file would have done a reasonable amount of lookup.
  2. We alter documentation to encourage users to override systemd units in the the usual way.
  3. Bonus option - we do both! :slight_smile:

On a second side note: I’m not sure that /etc/default/openhab gets changed without the user’s permission. This is set as a conffile for apt and yum so there should be some warning during installation that this file gets changed, apt gives an option for keeping the user version rather than the maintainer version.

5

If users change this file because they are instructed to do so, less experienced users will forget about these changes or will simply do not understand why apt is asking for overriding this file.

I like this idea:

but when it comes down to restoring a system I really think that linux.parameters, that is located in a directory which is part of the regular openhab-cli backup&restore mechanics, is the best option.

I’ll open a change request for that.

1 Like
6

Yep, fair enough! :slight_smile:

Thank you!

1 Like
7

Feature request created

1 Like
8

Great stuff. @Benjy already added this to oh5 and oh4. Many thanks!

Now we can add all our custom environment settings to this file and they won’t be overwritten anymore and are available in your interactive shell as well for openhab started in daemon mode.

1 Like