<div class="gmail_quote">On Tue, Apr 7, 2009 at 4:44 AM, Andrew Beekhof <span dir="ltr"><<a href="mailto:beekhof@gmail.com">beekhof@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tue, Apr 7, 2009 at 11:39, Dejan Muhamedagic <<a href="mailto:dejanmm@fastmail.fm">dejanmm@fastmail.fm</a>> wrote:<br>
> On Tue, Apr 07, 2009 at 08:07:27AM +0200, Andrew Beekhof wrote:<br>
>> Nothing in pacemaker - but the lrmd could be doing something that may<br>
>> be involved<br>
><br>
> AFAIK, it doesn't.<br>
<br>
</div>Ok, I was just thinking that its the one that ultimately spawns the<br>
process... so anything it did would also be inherited by the client.<br>
<br>
 btinsley: Perhaps look at /proc/<pid>/sched for the lrmd and aisexec<br>
processes.  That may give you an idea of where the settings are coming<br>
from.<br>
<div><div></div><div class="h5"><br>
><br>
>><br>
>> On Tue, Apr 7, 2009 at 02:21, btinsley <<a href="mailto:btinsley@gmail.com">btinsley@gmail.com</a>> wrote:<br>
>> > This is a little early in investigation on my end, but is there anything<br>
>> > that Pacemaker... or potentially OpenAIS, does that would restrict a cluster<br>
>> > resource from setting the scheduler type and/or priority? I have been<br>
>> > tinkering with KVM instances and there is a 100% repeatable difference<br>
>> > between how it behaves when Pacemaker starts the resource and when I start<br>
>> > it via the same OCF script on the command line (as the root user). When it<br>
>> > is started via Pacemaker, it seems to be unable to change its scheduler and<br>
>> > priority and eventually the whole system is brought to its knees and all<br>
>> > monitors get stuck in the "waiting on I/O" (D) state, which freaks Pacemaker<br>
>> > out...rightfully so ;-)<br>
>> ><br>
>> > Looking at /proc/<pid>/sched shows:<br>
>> ><br>
>> > ...<br>
>> > policy???????????????????????????? :??????????????????? 0<br>
>> > prio?????????????????????????????? :??????????????????? 0<br>
>> > ...<br>
>> ><br>
>> > And invoking the resource from the command line shows:<br>
>> ><br>
>> > ...<br>
>> > policy???????????????????????????? :??????????????????? 2<br>
>> > prio?????????????????????????????? :??????????????????? 120<br>
>> > ...<br>
>> ><br>
>> > Invoking ulimit with the -e and -r parameters with a value of "unlimited" in<br>
>> > the OCF script does no good. Thoughts?<br>
>> ><br>
>> ><br>
</div></div></blockquote></div><br><br>Thanks! I will do that this morning and go from there.<br><br><br>