Operating System - HP-UX
1833178 Members
2870 Online
110051 Solutions
New Discussion

msqtql tracking the size of the queue in this kernel variable and clearing it.

 
SOLVED
Go to solution
generic_1
Respected Contributor

msqtql tracking the size of the queue in this kernel variable and clearing it.

Does anyone have a simple C program or know of a tool that can do one or both of these two things.

1. See how full this queue is to see if it needs bumped up in the kernel settings.

2. Flush the queue when a program does bad cleanup.
5 REPLIES 5
generic_1
Respected Contributor

Re: msqtql tracking the size of the queue in this kernel variable and clearing it.

Ten points for a correct answers on this one! :)
Hemanth Gurunath Basrur
Honored Contributor

Re: msqtql tracking the size of the queue in this kernel variable and clearing it.

Hello Jeff,

I am attempting to answer your question here.

Are you discussing about msgtql here, which is a kernel parameter/tunable?

You can use the "Kernel Configuration" area in SAM to configure this kernel tunable.

You can also use the HP-UX Kernel Configuration tool (kcweb) that is available from SAM to view the current and next boot values. You can use the same on HP-UX 11i v2 system. kcweb is a Web-based kernel configuration tool. You can also set alarms for this tunable. In case, this tunable crosses the max. threshold value, a notification will be sent via console, email, opcmsg and other notification mechanisms.

HTH.

Regards,
Hemanth
generic_1
Respected Contributor

Re: msqtql tracking the size of the queue in this kernel variable and clearing it.

Good try, Basically my situation is my users are asking me to reboot my machine and increase this parameter because they suspect it is too low. However I think they application may also be leaving messages behind when it dies.

My first problem is that I would like to see with a tool that shows how much of the value is actually being utilized on the system.

My second problem is that I am looking for a tool that would clear out this queue if the app is being messy so I do not have to reboot the system and having the issue resurface multiple outages. I would imagine there is some C fuction that could be used in a short program to do this, but I do not know for sure. None the less it would be handy in my situation.

Thanks for your reply

generic_1
Respected Contributor

Re: msqtql tracking the size of the queue in this kernel variable and clearing it.

Good try, Basically my situation is my users are asking me to reboot my machine and increase this parameter because they suspect it is too low. However I think they application may also be leaving messages behind when it dies.

My first problem is that I would like to see with a tool that shows how much of the value is actually being utilized on the system. I do know what the current kernel settings are and how to change them.

My second problem is that I am looking for a tool that would clear out this queue if the app is being messy so I do not have to reboot the system and having the issue resurface multiple outages. I would imagine there is some C fuction that could be used in a short program to do this, but I do not know for sure. None the less it would be handy in my situation.

Thanks for your reply

A. Clay Stephenson
Acclaimed Contributor
Solution

Re: msqtql tracking the size of the queue in this kernel variable and clearing it.

What you are asking is not very easy; well actually it's easy to do but very difficult to do safely because usage and meaning of the message queue is strictly up to the set of cooperating processes using them. If you arbitrarily start a bunch of msgrcv()'s to clear a given queue, almost certainly you will introduce chaos into the intended protocol.

You can clear out a given message queue rather easily. Use ipcs -qa to get the desired message queue id (as well as other data) and then use ipcrm -q msgid to remove the queue.

You really need to ask your developers what errno is set to after a msgsnd() call fails and what arguments they were using. You also need to ask them what sort of signal handlers they have in place to clean up the message queues when the last process that uses them terminates. They also just might be right that you do need to bump up this limit.



If it ain't broke, I can fix that.