Languages

Menu
Sites
Language
Native service app terminated with SIGKILL after several hours

Hi all,

I've been developing a sensor monitoring service for the Samsung Gear Sport, using Tizen OS.

The service successfully captures data from the IMU and PPG sensors and stores them to a local sqlite database, but after 2.5 hours it mysteriously stops.

I ran it in the debugger and saw this:

 

Temporary breakpoint 2, main (argc=30, argv=0xfffef324) at ../src/testservice.c:81 81 char ad[50] = { 0, };

    c Continuing.

                                                   [2.5 hours pass.... ]

Program terminated with signal SIGKILL, Killed. The program no longer exists.

 

So Tizen is killing my service, despite the manifest including the 'sensor' and 'background-network' background categories set, and a CPU lock being applied.

The only thing I could find mentioning this online was here:

https://wiki.tizen.org/Service:Guideline

which implies that the systemd configuration for services includes the 'TimeOutSec' setting, causing the app to be automatically killed after a set period of time.

Is there any way I can stop this happening? Are all Tizen background services expected to be restarted after a couple of hours?

Appreciate any help or pointers you can give me.

Thanks in advance.

Edited by: Michael Gardner on 13 Apr, 2018
List

Responses

5 Replies
K Johnson

Hi Michael Gardner,

According to my understanding, you're looking for a solution about getting sensor data continuously without letting it killed. To avoid this you may try to set "alarm" on your program. Recommended interval is 10 minutes at least.

However, the solution is for making your program awake not sure whether it'll work in case of SIGKILL or not. You may give it a try and share your status here. Please go through GEUNSOO KIM's answer in this link for more detail.

Michael Gardner

Hi K Johnson,

Thanks for your reply - I tried adding the alarm, and unfortunately the service was terminated with SIGKILL again - this time after only 1 hour.

I added a signal() handler in for SIGTERM, SIGSEGV, etc. in case the service was given warning on the shutdown by the O/S, but it never fired. This leaves my service with absolutely no means of anticipating its shutdown. This will lead to data loss.

Has anyone else on this forum seen this behaviour? I find it hard to believe that Tizen makes it impossible to monitor its sensors continuously for such a relatively short time.

 

Thanks in advance,

Jonathan.

GEUNSOO KIM

I just wonder what you are doing in your service app, but check the followings

1. Is there any odd thing when it get killed? like 'the device got very hot temperature' or 'very laggy performance'

2. did you have any chance to check call stack when it happened? if the device leaves any crash dump, you can investigate it.

3. Are you still using CPU lock? If you are, you'd better remove it unless you are in experiment or using it very limited condition.
 

 

Michael Gardner

Thanks for your reply @Geunsoo Kim - I'll answer your points one-by-one:

 

1. No, nothing unusual. CPU usage is modest (around 6%) with no performance issues. My app is simply listening for PPG and IMU updates and writing them into a sqlite database, as well as streaming the data back to a phone over a bluetooth RFCOMM connection. All of this is progressing nicely for the hour or so leading up to the issue.

 

2. Unfortunately no - I don't have a chance to grab a call stack because I only get a SIGKILL - gdb tells me my service was terminated with SIGKILL, and even though I have a SIGKILL handler installed it never runs.

 

3. Yes, I am - but if I remove the CPU lock then I get 20-30 second gaps in my sensor data periodically. The watch must capture data with no gaps.

 

The application is for the watch to be a dedicated IMU and PPG sensor over the course of around 10 hours. It will not be used for anything else during this time.

 

K Johnson

Hi Michael Gardner,

Sorry for late response. Would you please share the log here?