MsgSendPulse

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

Hi

I’m trying to write a monitor process, the purpose of which is to receive
heartbeats from other processes, and restart them if they fail. The monitor
is a resource manager. I tried to use Pulses and MsgSendPulse as the
heartbeat mechanism, but this failed because the sending process had
insufficient permissions. Running the sending process as root solved the
problem.

It seems that a process must be running as root to be allowed to send
pulses to other processes running as root.

Is this correct? If yes, is there anything a resource manager can do to
allow clients to send them pulses?

I couldn’t find any documentation about this behaviour. I changed to using
messages instead of pulses, but pulses are a more suitable mechanism.

Thanks

Richard

2

Richard Wolf <richard@nsotsupdaemnt.usyd.edu.au> wrote:

Hi

I’m trying to write a monitor process, the purpose of which is to receive
heartbeats from other processes, and restart them if they fail. The monitor
is a resource manager. I tried to use Pulses and MsgSendPulse as the
heartbeat mechanism, but this failed because the sending process had
insufficient permissions. Running the sending process as root solved the
problem.

A different approch.

If you only need to detect if other process is exit, have them keep
an connection to your monitor (open("/dev/monitor")). When process
exit, it is guarenteed the fd be closed, so your close_ocb() handler
will be called…

-xtang


It seems that a process must be running as root to be allowed to send
pulses to other processes running as root.

Is this correct? If yes, is there anything a resource manager can do to
allow clients to send them pulses?

I couldn’t find any documentation about this behaviour. I changed to using
messages instead of pulses, but pulses are a more suitable mechanism.

Thanks

Richard

3

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:aj1sjp$gt$5@nntp.qnx.com…

Richard Wolf <> richard@nsotsupdaemnt.usyd.edu.au> > wrote:
Hi

I’m trying to write a monitor process, the purpose of which is to
receive
heartbeats from other processes, and restart them if they fail. The
monitor
is a resource manager. I tried to use Pulses and MsgSendPulse as the
heartbeat mechanism, but this failed because the sending process had
insufficient permissions. Running the sending process as root solved
the
problem.

A different approch.

If you only need to detect if other process is exit, have them keep
an connection to your monitor (open("/dev/monitor")). When process
exit, it is guarenteed the fd be closed, so your close_ocb() handler
will be called…

-xtang


It seems that a process must be running as root to be allowed to send
pulses to other processes running as root.

Is this correct? If yes, is there anything a resource manager can do to
allow clients to send them pulses?

I couldn’t find any documentation about this behaviour. I changed to
using
messages instead of pulses, but pulses are a more suitable mechanism.

Thanks

Richard

Thanks, I will do this as well, but I also need to be able to detect other
failure conditions, for example deadlocks. The application is an autonomous
solar powered boat hopefully capable of undertaking long range missions. If
any component fails the system obviously must be capable of detecting it and
restarting the process. What I want is something similar to the QNX High
Availability Manager, which we can’t use since we’re using the
non-commercial license.

Thanks
Richard

4

Richard Wolf <richard@nsotsupdaemnt.usyd.edu.au> wrote:

Thanks, I will do this as well, but I also need to be able to
detect other failure conditions, for example deadlocks. The
application is an autonomous solar powered boat hopefully
capable of undertaking long range missions. If any component
fails the system obviously must be capable of detecting it and
restarting the process. What I want is something similar to the
QNX High Availability Manager, which we can’t use since we’re
using the non-commercial license.

One of the techniques that we use, for simplicity, is to have 2
connections, one for each way. Obviously you can only send
message on one of them. But both are good for pulses. Basically
each manager registers a well known name using name_attach(),
from there connections can be made. If the processes also has be
resmgr, then we borrow the dispacth structure and chid from the
name_attach_t.

Might not be overly eligant, but, it is easy for all team
members to understand.

regards,
Tom

5

Richard Wolf <richard@nsotsupdaemnt.usyd.edu.au> wrote:

Hi

I’m trying to write a monitor process, the purpose of which is to receive
heartbeats from other processes, and restart them if they fail. The monitor
is a resource manager. I tried to use Pulses and MsgSendPulse as the
heartbeat mechanism, but this failed because the sending process had
insufficient permissions. Running the sending process as root solved the
problem.

It seems that a process must be running as root to be allowed to send
pulses to other processes running as root.

Is this correct? If yes, is there anything a resource manager can do to
allow clients to send them pulses?

Yes, this is correct. The docs for MsgSendPulse() are a bit odd…

You can send a pulse to any process in your process group if you
have the appropriate permissions to drop a signal on another process
(permission checking is identical to the checking used by the
kill() function).

The oddity is the bit about process groups – ignore that bit, but the
rest essentially says the rules are the same as for signals. Of course,
the rules for signals:

– you can send to processes with your own pid (that you own)
– root can send to processes with any pid


I couldn’t find any documentation about this behaviour. I changed to using
messages instead of pulses, but pulses are a more suitable mechanism.

Pulses do make a certain amount of sense for this behaviour, unfortunately
they do require the perms be right.

Hm… if you’re worried about the blockingness, and don’t want the clients
running as root, alternatives:

– have the resmgr have a thread/client, that essentially stays SEND/REPLY
blocked on the client. The client receives & stores away the rcvid,
and REPLYs regularly

– have the client have a thread that is in charge of making the sends
to the resmgr. Dispatch it internally in the client(s) using something
like a semaphore or a condition variable, and use the incrementing of
the semaphore/signalling of the condition variable as your heartbeat
call inside your client.


-David

–
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

6

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:aj8n0l$1e9$1@nntp.qnx.com…

Richard Wolf <> richard@nsotsupdaemnt.usyd.edu.au> > wrote:
Hi

I’m trying to write a monitor process, the purpose of which is to
receive
heartbeats from other processes, and restart them if they fail. The
monitor
is a resource manager. I tried to use Pulses and MsgSendPulse as the
heartbeat mechanism, but this failed because the sending process had
insufficient permissions. Running the sending process as root solved
the
problem.

It seems that a process must be running as root to be allowed to send
pulses to other processes running as root.

Is this correct? If yes, is there anything a resource manager can do to
allow clients to send them pulses?

Yes, this is correct. The docs for MsgSendPulse() are a bit odd…

You can send a pulse to any process in your process group if you
have the appropriate permissions to drop a signal on another process
(permission checking is identical to the checking used by the
kill() function).

The oddity is the bit about process groups – ignore that bit, but the
rest essentially says the rules are the same as for signals. Of course,
the rules for signals:

– you can send to processes with your own pid (that you own)
– root can send to processes with any pid


I couldn’t find any documentation about this behaviour. I changed to
using
messages instead of pulses, but pulses are a more suitable mechanism.

Pulses do make a certain amount of sense for this behaviour, unfortunately
they do require the perms be right.

Hm… if you’re worried about the blockingness, and don’t want the clients
running as root, alternatives:

– have the resmgr have a thread/client, that essentially stays
SEND/REPLY
blocked on the client. The client receives & stores away the rcvid,
and REPLYs regularly

– have the client have a thread that is in charge of making the sends
to the resmgr. Dispatch it internally in the client(s) using something
like a semaphore or a condition variable, and use the incrementing of
the semaphore/signalling of the condition variable as your heartbeat
call inside your client.


-David

Mmm thanks. When I stopped to think about it I realised that it makes sense
that the ability to send pulses is restricted. I imagine you could cause a
great deal of trouble.

I think I’ll stay with the messages, despite the possibility that they could
block. It occurred to me that if a monitor is to be guaranteed to work then
it needs to be running at the highest priority of all the tasks. This is
the only way to prevent it being preempted by a runaway thread stuck in some
sort of infinite loop. Since it is at the highest priority it will prevent
other threads from running anyway, whether they are blocked on MsgSend or
not.

Thanks again

Richard

7

Richard Wolf <richard@nsotsupdaemnt.usyd.edu.au> wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:aj8n0l$1e9$> 1@nntp.qnx.com> …
Richard Wolf <> richard@nsotsupdaemnt.usyd.edu.au> > wrote:
Hi

I’m trying to write a monitor process, the purpose of which is to
receive
heartbeats from other processes, and restart them if they fail. The
monitor
is a resource manager. I tried to use Pulses and MsgSendPulse as the
heartbeat mechanism, but this failed because the sending process had
insufficient permissions. Running the sending process as root solved
the
problem.

Mmm thanks. When I stopped to think about it I realised that it makes sense
that the ability to send pulses is restricted. I imagine you could cause a
great deal of trouble.

Because pulses are also used for transferring system information,
like unblock/disconnect, yup.

I think I’ll stay with the messages, despite the possibility that they could
block. It occurred to me that if a monitor is to be guaranteed to work then
it needs to be running at the highest priority of all the tasks. This is
the only way to prevent it being preempted by a runaway thread stuck in some
sort of infinite loop. Since it is at the highest priority it will prevent
other threads from running anyway, whether they are blocked on MsgSend or
not.

Be careful – QNX floats the priority of the server thread to that
of the client which sent it a message. If your monitor process is
handling a client’s notification, it could get pre-empted by a
higher priority thread elsewhere, possibly one that is “failing”
by running READY.

By using pulses for regular system-sanity wakeups, and by making
sure the pulse you receive is very high priority (higher than any
other thread in the system, 63 is a possible choice), you can make
sure the (a) monitor thread will be run at this high priority to
check for system integrity.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.