-Dmbsa.lib.core.log

-

-Dmbsa.lib.core.log.parts

core.log.parts

-Dmbsa.lib.core.log.maxsize

core.log.maxsize

-Dmbsa.lib.core.log.maxcount

core.log.maxcount

-Dmbsa.lib.core.log.enable

core.log.enable

core.log.file

-

Specifies the core log file. Default value is ./logs/mbsa_start.log

mbsa.log.file

-

Specifies the mBSA start/stop log files.

Modify these properties in the mbsa_start/mbsa_stop scripts.

-

core.plugins.log.dir

Specifies the log directory of plug-ins. Default value is ./logs

core.log.enable

core.plugins.log.enable

Can be true or false. Defines if the logging for core/all plug-ins is enabled or disabled.

core.log.maxsize

core.plugins.log.maxsize

Defines the maximum size (in kilobytes) of single core/plugin logs. When 0, no maximum size is set.

core.log.maxcount

core.plugins.log.maxcount

Defines the maximum log files per core/plugin. When the plugin or the core log's count exceeds this value, the oldest logs are deleted. Set it to 0 for no restriction on the count of log files.

core.log.parts

core.plugins.log.parts

Defines the runtime log parts. Each log file will be with size = maxsize/parts. Used only if maxsize is set.

core.plugins.dir

../lib/runtimes/OS*/plugins (default value replaced by mbsa_start/stop scripts depending on OS)

Directory where the plugins libraries are. When mBSA starts, it looks for plugins in this directory, given absolute or relative to the '<mBSA>/' directory.

core.autostart.list

mbsap.tm, mbsap.comms, mbsap.tmmodule, mbsap.rtc, mbsap.watchdog.os, mbsap.mbsmanager, mbsap.fileaccess

Autostart list - comma separated list of mBSA plugins that will be auto initialized on mBSA start. Their PPlugin::init() methods will be called. If one of the autostart plugins fail to initialize itself then the whole core will be stopped.

core.plugins.config.dir

./configs/OS*

Config directory of plugins. Here are the *.prs files that contain configuration properties for each plugin.

core.plugins.log.dir

./logs

Log directory of plugins. Here the *.log files are stored.

core.plugins.log.level

1

Defines log level, which can be any non-negative number. The level logs will appear only if their level is not greater than this value. For example, if you set level 2, then only logs with level 0, 1 and 2 will be logged.

core.notify.exit.timeout

300

Notify timeout for exit of mBSA in seconds. When mBSA is stopped normally, it waits for this amount of time, thus giving a chance to plugins and other software to prepare for stopping.

core.free.plugins.lib

false

Flag to free plugins lib or not. Set to "false" to speed-up the exit of core.

comms.use.tmclient

false

Use Target Manager Comms. If set to true, the Comms of the Target manager plugin will be used. The false value is set when the configuration is for central mBSA and true value is set for all other mBSA cores which are clients in terms of Target Manager.

comms.tcp.transport.server.enable

true

Enable/Disable flag for TCP transport. Currently there is only this type of network supported so this property has to be always true to be able to work with Comms.

comms.tcp.transport.server.host

0.0.0.0

Put here the interface on which to listen. Specify a valid IP or host. If 0.0.0.0 is used, the Comms listens on all network interfaces, but the board must be able to resolve its own IP through hostname (e.g. ping `hostname` should return the real IP of the board). If network configuration is incomplete, either export MBSA_HOST_IP={real ip} in mBSA start scripts, or use 127.0.0.1 here, which will disable remote tooling access to the mBSA.

comms.tcp.transport.server.port.range.start

5670

Start of port range on which to start listening. For central mBSA always put here two ports, because settings for Comms client plugins such as Target Manager Comms Client need to discover the central core. For mBSA which runs as Comms client in terms of TargetManager the port range could be any one.

comms.tcp.transport.server.port.range.end

5671

End of port range on which to start listening.

extcounters.enabled

false

Specify if the extcounters plug-in is enabled.

extcounters.process_timeout

30000

Time (milliseconds) to wait for the external process to finish.

fileaccess.read

../../osgi/bin/vms

Comma separated list of directories where File Access has read permission.

fileaccess.write

Comma separated list of directories where File Access has write permission.

fileaccess.read.recursive

../../osgi/bin/vms

Comma separated list of directories where File Access has recursive read permission.

fileaccess.write.recursive

Comma separated list of directories where File Access has recursive write permission.

global.app.name

mbsa3.3

Global application name.

rtc.timeout.runtime.start

120

Timeout for starting runtime in seconds (may need to be increased depending on the hardware). It is advised to measure startup time without storage (clean configuration) and add some overhead e.g. 20-30s for linux boot time processes. If this timeout is exceeded, the mBSA will kill the Bosch IoT Gateway Software.

rtc.timeout.runtime.stop

60

Timeout for stopping runtime in seconds. If you want faster shutdown, do not allow a big overhead, e.g. if some bundle stop takes too long, Bosch IoT Gateway Software will be killed.

rtc.on.exit.wait.for.runtime.start

false

Flag to wait for runtime start when the core is exited. If this flag is false all starting runtimes on core exit will be killed. This property controls RTC behavior, when the RTC stop request comes, while the runtime is still starting. If true, the RTC stop will wait for normal startup, then it will stop it gracefully.

If the runtime freezes during startup and rtc.timeout.runtime.start will be exceeded and the runtime killed, then the RTC stop will just log an error.

rtcclient.transport.id

com.prosyst.mbsa.transport.tcp

Main mBSA core comms transport id.

rtcclient.transport.data

127.0.0.1:5670

Main mBSA core comms transport data.

rtcclient.transport.second.id

com.prosyst.mbsa.transport.tcp

Second mBSA core comms transport id.

rtcclient.transport.second.data

127.0.0.1:5671

Second mBSA core comms transport data.

rtcclient.sendmsg.timeout

30000

Timeout in milliseconds for sending message.

threadguard.watchdog.hwd.enable

true

Enable using of watchdog HWD.

threadguard.watchdog.hwd.period

30

Watchdog HWD ping period in seconds.

tmclient.transport.id

com.prosyst.mbsa.transport.tcp

Main mBSA core comms id.

tmclient.transport.data

127.0.0.1:5670

Main mBSA core comms data.

tmclient.transport.second.id

com.prosyst.mbsa.transport.tcp

Second mBSA core comms id.

tmclient.transport.second.data

127.0.0.1:5671

Second mBSA core comms data.

tmclient.sendmsg.timeout

30000

Timeout in milliseconds for sending message.

watchdog.hwd.period

30

Watchdog HWD ping period in seconds

watchdog.hwd.executable

External executable that performs Watchdog HWD checks.

watchdog.hwd.options.enable

0

Watchdog HWD enable options; period is in minutes.

watchdog.hwd.options.disable

0

Watchdog HWD disable options; period is in minutes.

watchdog.hwd.options.tick

0

Watchdog HWD tick options.

watchdog.hwd.number

2

Watchdog number used for custom code. Can be ignored - it is used when there are multiple hw watchdogs responsible for different modules and "2" is the mBSA watchdog number.

watchdog.os.period

5

Watchdog OS ping period in seconds. This is the period of sampling the monitored values, such as memory and CPU usage.

watchdog.os.level.freemem

1024

Free memory level in kilobytes. If the free memory goes below this point, an event will be sent.

watchdog.os.level.memperiod

60

Free memory interval in seconds. This is the interval for memory sampling.

watchdog.os.level.cpuuse

95

CPU usage level in %. If the CPU usage goes above this point, an event will be sent.

watchdog.os.level.cpuperiod

60

CPU usage interval in seconds. This is the interval for memory sampling.

watchdog.os.cpu.sendevent

true

Enable or disable sending events for CPU limit. Determine to send events in this case or not.

watchdog.os.mem.sendevent

true

Enable or disable sending events for memory limit. Determine to send events in this case or not.

watchdog.os.check.cpuuse

true

CPU usage on/off. If false, CPU usage will not be checked.

watchdog.os.check.memlow

true

Mem low on/off. If false, memory usage will not be checked.

watchdog.os.restart

false

Enable or disable OS restart. If false, the system will not be actually restarted, even if such action is set. However, a message will be put into a log file.

watchdog.os.cpu.action

none

Possible values for actions when CPU limit is reached: none, restart, execute, execute&restart, interface.

watchdog.os.cpu.executable

Path to process executable or script for CPU event. If action is set to "execute" or "execute&restart", this is the path to the application that will be executed.

watchdog.os.cpu.arguments

Arguments given for process executable for CPU event.

watchdog.os.cpu.workingdir

Working directory in which to execute process for CPU event.

watchdog.os.cpu.interfaces

com.prosyst.mbsa.mbs.confirm.restart

List of interface IDs to notify for MEM event. These interfaces must implement IEventListener interface. If the action is set to "interface", all of the interfaces in the list will be called in case of CPU event.

watchdog.os.mem.executable

Path to process executable or script for MEM event.

watchdog.os.mem.arguments

Arguments given for process executable for MEM event.

watchdog.os.mem.workingdir

Working directory, in which to execute a process for MEM event.

watchdog.os.mem.interfaces

com.prosyst.mbsa.mbs.confirm.restart

List from interface IDs to notify for MEM event. Must implement IEventListener.

General Settings for Plugin

watchdog.process.cpu_enabled

false

Enable or disable all CPU checks.

watchdog.process.mem_enabled

false

Enable or disable all memory checks.

watchdog.process.inst_enabled

false

Enable or disable all instance checks.

watchdog.process.sample_time

2

Sample time between all checks for all processes in seconds.

Main Processes

watchdog.process.1.name

 proc-name

Name of the process to check limits/respawning. The number "1" refers to the first monitored process. The other properties, containing the same number also refer to the same process. The second process's name will be with "2" instead. Use sequential numbers starting with "1". If the name is not set, all other properties will not be read.

watchdog.process.1.period

5

Period for all limits to check in seconds.

watchdog.process.1.send_event

false

Send EventDispatcher event for limits. This refers to sending events that are global to mBSA.

CPU Processes

watchdog.process.1.cpu_enabled

false

Enable or disable CPU limit check.

watchdog.process.1.cpu_limit

5

Percentage of CPU usage.

Memory Processes

watchdog.process.1.mem_enabled

false

Enable or disable memory limit check.

watchdog.process.1.mem_limit

10485760

Memory limit in bytes.

Instances Processes

watchdog.process.1.inst_enabled

false

Enable or disable instance limit check.

watchdog.process.1.inst_limit

2

Number of instances for which to generate action/event.

watchdog.process.1.count_only_diff_parents

true

Flag to count only different parents instances.

watchdog.process.1.count_only_running

true

Flag to count only different instances.

Instance Respawn Processes

watchdog.process.1.respawn_enabled

false

Enable or disable minimum instance re-spawn logic. Ignored if watchdog.process.inst_enabled is not enabled.

watchdog.process.1.respawn_limit

1

If respawn is enabled, defines the minimium number of instances of the monitored process. If running instances are below this value, a new process is respawned.

Actions Processes

watchdog.process.1.action

 none

The action to take whenever a limit has been reached. Possible values are: none - no action, terminate - terminate the process, restart - restart the process (see .executable, .arguments., and .workingdir below), osrestart - restart the OS.

watchdog.process.1.executable

Process to execute in case of restart action or re-spawn event.

watchdog.process.1.arguments

Arguments to pass in case of restart action or re-spawn event.

watchdog.process.1.working_dir

Working directory to execute in case of restart action or re-spawn event.

os.restart.executable

OS Restart executable. An external application that will be executed before Internal restart (if enabled).

Timeout for this executable is 30s; if the process did not finish, the internal restart is pending.

If the set and the execution of an external application returns an error, an internal restart is enforced even if os.restart.internal.follow = false

You may define a custom script, which allows you to do custom actions before the restart (but it cannot be blocked for too long - if not finished within 30s, the restart process continues).

os.restart.arguments

${os.restart.executable} executable arguments. The iReserved parameter of IOSRestart::restart(...) is added to the end of arguments as 32-bit integer.

os.restart.internal.follow

false

Flag to do internal restart after execution of ${os.restart.executable}. This can be used to make executable to be used for pre restart sequence or in case it does not restart, to do internal restart always. This property should be set to true to force restart if the restart executable failed or timed out.

You should also allow the Bosch IoT Gateway Software manager to do OS restarts: "mbs.manager.os.restart = true".

This flag must be set to true, if ${os.restart.executable} is empty, otherwise the OS restart will be disabled. This property should be set to true also to force restart if restart executable failed or timed out.

mbs.manager.default.target.type

com.prosyst.mbs.framework

Default target type to start. The Bosch IoT Gateway Software manager will not auto start the runtime if the target type property is not set or is empty.

mbs.manager.default.target.mode

Default target mode for auto starting. It should be "", unless you want to start Bosch IoT Gateway Software in debug / profile mode initially.

mbs.manager.ping.timeout

60

How long to wait for the watchdog ping from the framework in seconds. Not really advisable as this means Bosch IoT Gateway Software will have to ping in less than 5s, which is easily delayed by some operations in e.g. synchronous framework listeners (Remote Management Provisioning Agent tries to do network operation there) and even 30s may be very unsafe. But one can experiment with this. You must also change "mbs.mbsa.ping.timeout" in mbsa/bin/vms/mbsa.sh: # Bosch IoT Gateway Software watchdog setup (ping timeout should be "mbs.manager.ping.timeout" / 2). mbs.mbsa.commsErrors ( if > 0, the gatway will exit after specified comms send errors) export FEATURES= "$FEATURES -Dmbs.comms=comms3 -Dmbs.mbsa.ping.timeout=30000 -Dmbs.mbsa.commsErrors=3"to something smaller, e.g. ping Bosch IoT Gateway Software Manager plugin each 5000ms.

mbs.manager.restart.max

6

The number of unexpected framework exits or crashes, after which the mBSA restarts the OS. If set to 0, the OS is restarted immediately on the first crash/timeout/fault of Bosch IoT Gateway Software. If set to X >= 2, the mBSA restarts the Bosch IoT Gateway Software (X-1) times, and after that restarts the OS. If mbs.manager.os.restart = false, the mBSA just stops restarting the Bosch IoT Gateway Software.

mbs.manager.restart.interval

700

Interval to check maximum restart count rate in seconds. If more than mbs.manager.restart.interval seconds passed since last restart timestamp, restart counter is reset back to 1 and restart timestamp is set at current time.

Make sure this is > ${mbs.manager.restart.max} * {rtc.timeout.runtime.start} + some overhead (e.g. 100s) mbs.manager.restart.interval = 700

It is always better to consult comments in the mbsa prs files, are they are more frequently updated than documentation. In some cases Bosch IoT Gateway Software restarts are not necessary or probably allowed for max 2 restarts, followed by an OS restart. Other hw watchdog projects can be configured to restart immediately after Bosch IoT Gateway Software timeout, crash or unexpected server exit. But this is not feasible for development and in such cases you should disable OS restarts (mbs.manager.os.restart = false)

mbs.manager.fwnotify.waittime

5

Time in seconds to wait after sending FW notification and before restarting the OS/Bosch IoT Gateway Software.

Update Manager configuration

mbs.manager.update.dir

../..

Base directory, containing mbsa/, osgi/ and persistent update storage (in case of osgi updates). If empty, the Update Manager does not check for required directories.

mbs.manager.update.jvm.dir

Current JVM directory, if empty the JVM Update is disabled!

mbs.manager.fwvalidation.waittime

150

Time in seconds to wait for faults during FW validation after the FW started.

mbs.manager.os.restart

false

Enable or disable OS restart.

mbs.manager.rtc.1.target_type

com.prosyst.mbs.framework

Target type of the runtime.

mbs.manager.rtc.1.version

1.0

Target type version of the runtime.

mbs.manager.rtc.1.properties

Properties of the runtime. Used for mToolkit Eclipse plugin only.

• mbs.manager.rtc.1.properties:debug = server=y,suspend=y,address=8000
• mbs.manager.rtc.1.properties:profile = attach=5115
• mbs.manager.rtc.1.properties:profile_jvmti = attach=5115
• mbs.manager.rtc.1.properties:validate =

mbs.manager.rtc.1.working_dir

../../osgi/bin/vms/jdk

Working directory for executable.

mbs.manager.rtc.1.exec

./server.sh

Executable of the runtime.

For SDK version < 8.0 use ./server script) and for Windows OS - ./server.bat)

mbs.manager.rtc.1.args

Arguments to pass to executable.

• mbs.manager.rtc.1.args = ../../../../mbsa/bin/vms/mbsa.sh
• mbs.manager.rtc.1.args:debug = ../../../../mbsa/bin/vms/mbsa.sh debug dbg_suspend
• mbs.manager.rtc.1.args:profile = ../../../../mbsa/bin/vms/mbsa.sh profiler suspend
• mbs.manager.rtc.1.args:profile = ../../../../mbsa/bin/vms/mbsa.sh profiler jvmti suspend
• mbs.manager.rtc.1.args:validate = ../../../../mbsa/bin/vms/mbsa.sh validate

mbs.manager.rtc.1.monitored

true

Monitoring could be disabled while debugging/profiling to prevent timeouts, faults, etc. If false the runtime is not monitored for ping timeouts, and faults from the runtime are ignored. E.g. the following configuration monitors only the default mode and allows debugging / profiling without monitoring to prevent timeouts, faults, etc:

• mbs.manager.rtc.1.monitored:debug = false
• mbs.manager.rtc.1.monitored:profile = false
• mbs.manager.rtc.1.monitored:profile_jvmti= false

This allows to modify default monitoring actions for Bosch IoT Gateway Software Manager plugin depending on target.mode. E.g. you may enable monitoring for debug mode, unless you do not block important framework threads which could lead to OS restart.

mbs.manager.rtc.1.env

Environment to pass to the executable. The environments need to be in format key1=value1|key2=value2|...

mbs.manager.rtc.1.multiple

true

Multiple instance flag.

mbs.manager.rtc.1.kill_exec

Kill executable. You may define your own script for killing the JVM e.g. (killall -9 java); by default mBSA will kill the process tree for ${mbs.manager.rtc.*.exec}.

mbs.manager.rtc.1.kill_args

Kill executable arguments.

mbs.manager.rtc.1.kill_working_dir

Working directory for kill executable.

mbs.manager.rtc.*.exec, mbs.manager.rtc.*.args, mbs.manager.rtc.*.working_dir and mbs.manager.rtc.*.env allow customization for Bosch IoT Gateway Software start scripts / environment / etc. E.g. they are handled like the following pseudo script: export ${mbs.manager.rtc.*.env} cd ${mbs.manager.rtc.*.working_dir} ./${mbs.manager.rtc.*.exec} ${mbs.manager.rtc.*.args}

mbs.manager.rtc.1.kill_env

Environment to pass to the kill executable. The environments (envs) need to be in format key1=value1|key2=value2|...

mbs.manager.rtc.1.reset_autostart

false

Reset autostart flag. When runtime is restarted due to autostart flag, the flag will be set to false to prevent following restarts.

JVM CPU/Memory/Instances Monitoring Processes

You need to enable global cpu/mem/inst monitoring in mbsap.watchdog.process.prs.

mbs.manager.mbs_watchdog.process_name

[String] The name of the JVM process.

Append extension for Win32 (e.g. java.exe).

If multiple JVM processes are expected to exist on host, rename the JVM executable to a unique process name e.g. (java-gws-10.1).

mbs.manager.mbs_watchdog.period

5

[Integer] Period of time over which to measure in seconds.

mbs.manager.mbs_watchdog.cpu_enabled

false

[Boolean] Whether CPU monitoring is enabled.

mbs.manager.mbs_watchdog.cpu_limit

95

[Integer] CPU limit for the process as percentage [0-100] / [CPU Count].

CPU% is scaled by CPU Count in multi core systems (e.g. in dual core max CPU will be 200%). Usually JVM will consume 100% for a single CPU, so suggested MAX value for dual core is 50%.

mbs.manager.mbs_watchdog.mem_enabled

false

[Boolean] Whether memory monitoring is enabled.

mbs.manager.mbs_watchdog.mem_limit

10485760

[Integer] Memory limit for the process in Bytes.

mbs.manager.mbs_watchdog.inst_enabled

false

[Boolean] Whether instance count monitoring is enabled.

mbs.manager.mbs_watchdog.inst_limit

2

[Integer] Instance count limit.

mbs.manager.mbs_watchdog.count_only_diff_parents

true

[Boolean] When set, counts only process instances with same name but different parents (to counter the case when threads show up as child processes).

mbs.manager.mbs_watchdog.count_only_running

true

[Boolean] When set, counts only running instances (to disable counting zombies).

mbs.manager.mbs_watchdog.cpu_limit.action

none

[String] Actions to execute on CPU, Mem, Inst limit event:

• none – do nothing,
• restart – restart Bosch IoT Gateway Software,
• restart_clean – restart Bosch IoT Gateway Software with clean storage,
• restart_os – restart OS,
• restart_os_clean – restart OS with clean storage.

These are the Bosch IoT Gateway Software Manager specific actions. Process Watchdog action is 'none' + event sending.

mbs.manager.mbs_watchdog.mem_limit.action

none

mbs.manager.mbs_watchdog.inst_limit.action

none

mbs.manager.storage.cleanup.exec

../../osgi/bin/vms/storage_cleanup.sh

Executable to do Bosch IoT Gateway Software storage clean-up. This is a script, which handles Bosch IoT Gateway Software Faults/Restart requests with clean storage. This script is OK if you have default storage location, if not (or in case storage is a symlink to another directory) - you should specify storage directory explicitly: mbs.manager.storage.cleanup.arguments=/path_to_storage/storage.

mbs.manager.storage.cleanup.workingdir

none

Working directory for storage clean-up exec.

mbs.manager.storage.cleanup.arguments

none

Arguments to execute storage clean-up exec.

mbs.manager.factory.reset.exec

none

Executable for OS factory reset.

OS Factory reset script is called when OSGi is still running. This may cause storage corruption after restoring the factory storage, so the script must contain a line to kill the running JVM (java, siege, etc): killall -9 java siege # then restore factory storage

If there are other JVMs running, it is advisable to create a symlink e.g. /jvm/bin/java to /jvm/bin/java-gws and killall the java-gws only.

mbs.manager.factory.reset.workingdir

none

Working directory for OS factory reset exec.

mbs.manager.factory.reset.arguments

none

Arguments for OS factory reset exec.

mbs.manager.update.firmware.exec

none

Firmware update executable.

mbs.manager.update.firmware.workingdir

none

Firmware update work directory.

mbs.manager.update.firmware.arguments

none

Firmware update arguments.