Symbian Developer Network

Have written a Watchdog application to kill and restart another application I am running an N95. While the Watchdog is simply a console application with a checking ActiveObject, the Watchdog stops working at some unknown point in the future. After about 1 hour the Watchdog just dies. I'm fairly certain the code is good (no memory leaks). The Watchdog is super simple.

Q. Is there any way to make sure that a Process is run continuously and that Symbian OS does not affect the Process thread in any way i.e. shut it down at its own initiative.

Q. Am I seeing this correctly? The OS seems to be shakey when running applications in background for extended periods of time.

The Active Object Code

#include "ProcessWatcher.h"
#include

extern RFileLogger *log;

CProcessWatcher::CProcessWatcher() :
CActive(EPriorityStandard) // Standard priority
{
}

CProcessWatcher* CProcessWatcher::NewLC()
{
CProcessWatcher* self = new ( ELeave ) CProcessWatcher();
CleanupStack::PushL(self);
self->ConstructL();
return self;
}

CProcessWatcher* CProcessWatcher::NewL()
{
CProcessWatcher* self = CProcessWatcher::NewLC();
CleanupStack::Pop(); // self;
return self;
}

void CProcessWatcher::ConstructL()
{
User::LeaveIfError(iTimer.CreateLocal() ); // Initialize timer
CActiveScheduler::Add( this); // Add to scheduler
}

CProcessWatcher::~CProcessWatcher()
{
Cancel(); // Cancel any request, if outstanding
iTimer.Close(); // Destroy the RTimer object
iProcess.Close(); //Close the Process
// Delete instance variables if any
}

void CProcessWatcher::DoCancel()
{
iTimer.Cancel();
}

void CProcessWatcher::StartL(TTimeIntervalMicroSeconds32 aDelay)
{
Cancel(); // Cancel any request, just to be sure
iState = EUninitialized;
iTimer.After(iStatus, aDelay); // Set for later
SetActive(); // Tell scheduler a request is active
}

void CProcessWatcher::RunL()
{
if (iState == EUninitialized)
{
// Do something the first time RunL() is called
iState = EInitialized;
CheckAndRun();
}
else
{
if (iState != EError)
{
CheckAndRun();
}
}
iTimer.After(iStatus, 300000000); // Do kill every hour
SetActive(); // Tell scheduler a request is active
}

TInt CProcessWatcher::RunError(TInt aError)
{
return aError;
}

TBool CProcessWatcher::IsApplicationRunning(void)
{
TBool Ret(EFalse);

TFileName res;
TFindProcess find;

while(find.Next(res) == KErrNone)
{
RProcess ph;
ph.Open(res);

if(ph.SecureId() == 0x00000013)
{
Ret = ETrue;
break;
}

ph.Close();
}

return Ret;
}

void CProcessWatcher::CheckAndRun()
{

//Check if Application is Running
TBool running = IsApplicationRunning();

log->WriteFormat(_L("Iteration = %d"), iIteration);

if (running)
{
log->Write(_L("CProcessWatcher::RunL:Application is ON..."));

if (iIteration >= 12)
{

//Application is Running
iProcess.Kill(0);
log->Write(_L("CProcessWatcher::RunL:Application KILLED..."));
//Attempt to Start Application
iProcess.Create(KApplicationExeFile, KNullDesC);
iProcess.Resume();
log->Write(_L("CProcessWatcher::RunL:Re-starting Application..."));

iIteration = 0; //reset the counter
}

}
else
{
//Application is not Running
log->Write(_L("CProcessWatcher::RunL:Application is OFF..."));
//Attempt to Start Application
iProcess.Create(KApplicationExeFile, KNullDesC);
iProcess.Resume();
log->Write(_L("CProcessWatcher::RunL:Ran Application Executable"));
iIteration = 0; //reset the counter

}

iIteration++; //Increment the iteration

}

TInt CProcessWatcher::whatIsBatteryLevel()
{
TInt level = 0;

//To be completed.

return level;
}

MaxPayne

So what would you use as a solution other than a Timer? What is the alternative? I need a timed polling check.

Thought it was dangerous to use Synchronous Timer (User::After).

Thanks for the positive help Max. What's so silly about checking that a Process is running every 5 minutes?

Hi Rudikball,

The reason that maxpayne says that polling is evil, is because you need to run your polling code on a timer even if the watched process is in a good state.
On mains power that (arguably) might be fine, but on a resource contrained device you're consuming clock cycles you don't need to (draining the battery). Even worse, you're potentially waking up the phone from a low power mode.

Since phone manufacturer standby times are dependent on the phone really being idle, you may be reducing the amount of time between recharges to a noticeable level.

Instead, you can use an undertaker (RUndertaker) to notify your code when the process is dead and that it shoudl run. Then your code is quiescent unless needed.

Regards
Hamish Willee
Symbian Ltd.

Hi rudikball,

The timers are trustworthy, they cannot be the reason your application is failing. Please stop saying it is because of Symbian OS - it isn't. Many other applications run ok - the phone application for example - if that didn't run for a long time, it wouldn't be much use as a phone?

The reason people are saying not to use RTimer is because for what you want to do, it wastes battery power.

By using RTimer, you are forcing the OS to keep checking a counter value until your time limit is hit and this forces the CPU to stay in a high-power state, using more of the battery.

If you use RUndertaker (or RProcess::Logon), your watchdog app will go to sleep (i.e. stop running) until it is triggered (by the other application stopping). By going to sleep, it means the CPU can go into a low-power state and save battery.

I hope that makes it clearer?

The main problem though is your main application stopping running. It is not a failure of the OS. It is a defect in the application and you need to debug it to find out what the problem is.

Hi ~rudikball,

This will be my last post in this thread, since its already become bit of a drag.

Firsty, READ THE DOCUMENTATION! If you actually did, you'd see that RTimer::After uses TTimeIntervalMicroSeconds32, which has the following to say in the docs:

Description

Represents a microsecond time interval stored in 32 rather than 64 bits.

Its range is +-2147483647, which is +-35 minutes, 47 seconds.

And then there's your code (which I still bet hasn't been changed to take account of error checking I mentioned earlier and also time changes due to system time change):


iTimer.After(iStatus, 300000000); // Do kill every hour

O yeah... also if my high school maths is correct, one hour translated to microseconds is 3600000000.

Anyway, blaming the OS isn't going to take you anywhere if you don't know how to use the APIs and can't be bothered to read the documentation AND the recommended solution for your scenario.

Hope that helps.