[Xenomai] rt_task_create fails when running over ssh

[Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

Hi Folks,

I just hit the problem where my simple user-space application which
uses rt_task_create() fails if started from the console session
running over ssh. The error code returned by rt_task_create() is
"-EPERM is returned if this service was called from an asynchronous
context".

Since I did not found further information in the documentation, I
would really appreciate if someone can say some words (or point to the
information source) why this function does not like if the program is
running over ssh and how to solve this issue.

Thank you,
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

Andrey Nechypurenko wrote:
> Hi Folks,
>
> I just hit the problem where my simple user-space application which
> uses rt_task_create() fails if started from the console session
> running over ssh. The error code returned by rt_task_create() is
> "-EPERM is returned if this service was called from an asynchronous
> context".
>
> Since I did not found further information in the documentation, I
> would really appreciate if someone can say some words (or point to the
> information source) why this function does not like if the program is
> running over ssh and how to solve this issue.

Another reason for -EPERM is if the application is not launched as root.
For using Xenomai as a non-root user, see:

http://www.xenomai.org/index.php/Non-root_RT

-- 
                    Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

> Another reason for -EPERM is if the application is not launched as root.
> For using Xenomai as a non-root user, see:

Thanks Gilles for the hint, but I was loggin in as root with ssh.

Regards,
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

Andrey Nechypurenko wrote:
>> Another reason for -EPERM is if the application is not launched as root.
>> For using Xenomai as a non-root user, see:
>
> Thanks Gilles for the hint, but I was loggin in as root with ssh.

Ok, but there is no code in xenomai which accesses or relies on the console
could you try to run the latency test from the ssh console to see if you
get the same issue?

-- 
                    Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

> Ok, but there is no code in xenomai which accesses or relies on the console
> could you try to run the latency test from the ssh console to see if you
> get the same issue?

xeno-test works just fine. So I assume that it is related to how I am
compiling the example. I've tried trivial-periodic.c using the
following command to compile:

ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- CFLAGS="
-march=armv7-a -fno-tree-vectorize -mthumb-interwork
-mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 " LOCALVERSION=""
arm-angstrom-linux-gnueabi-gcc
-I/home/bbcross/rootfs/usr/include/xenomai/ -D_GNU_SOURCE -D_REENTRANT
-D__XENO__ -L/home/bbcross/rootfs/usr/lib -lxenomai -lnative
trivial-periodic.c -o trivial-periodic

The resulting file runs as expected from the serial console, but
rt_task_create() fails with the same -EPERM error if running over ssh
as root. Do you see anything wrong with the command line above?

Thanks,
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

Andrey Nechypurenko wrote:
>> Ok, but there is no code in xenomai which accesses or relies on the
>> console
>> could you try to run the latency test from the ssh console to see if you
>> get the same issue?
>
> xeno-test works just fine. So I assume that it is related to how I am
> compiling the example. I've tried trivial-periodic.c using the
> following command to compile:
>
> ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- CFLAGS="
> -march=armv7-a -fno-tree-vectorize -mthumb-interwork
> -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 " LOCALVERSION=""
> arm-angstrom-linux-gnueabi-gcc
> -I/home/bbcross/rootfs/usr/include/xenomai/ -D_GNU_SOURCE -D_REENTRANT
> -D__XENO__ -L/home/bbcross/rootfs/usr/lib -lxenomai -lnative
> trivial-periodic.c -o trivial-periodic

If your compiler compiles for thumb by default, please add -marm on the
command line.

>
> The resulting file runs as expected from the serial console, but
> rt_task_create() fails with the same -EPERM error if running over ssh
> as root. Do you see anything wrong with the command line above?

Could you try to run the latency test without xeno-test ?

-- 
                    Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

Andrey Nechypurenko wrote:
>> Ok, but there is no code in xenomai which accesses or relies on the
>> console
>> could you try to run the latency test from the ssh console to see if you
>> get the same issue?
>
> xeno-test works just fine. So I assume that it is related to how I am
> compiling the example. I've tried trivial-periodic.c using the
> following command to compile:
>
> ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- CFLAGS="
> -march=armv7-a -fno-tree-vectorize -mthumb-interwork
> -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 " LOCALVERSION=""
> arm-angstrom-linux-gnueabi-gcc
> -I/home/bbcross/rootfs/usr/include/xenomai/ -D_GNU_SOURCE -D_REENTRANT
> -D__XENO__ -L/home/bbcross/rootfs/usr/lib -lxenomai -lnative
> trivial-periodic.c -o trivial-periodic

It should be -lnative -lxenomai, please use the xeno-config to obtain the
flags, do not hardcode them.


-- 
                    Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

On 3 November 2012 15:09, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
> Andrey Nechypurenko wrote:
>>> Ok, but there is no code in xenomai which accesses or relies on the
>>> console
>>> could you try to run the latency test from the ssh console to see if you
>>> get the same issue?
>>
>> xeno-test works just fine. So I assume that it is related to how I am
>> compiling the example. I've tried trivial-periodic.c using the
>> following command to compile:
>>
>> ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- CFLAGS="
>> -march=armv7-a -fno-tree-vectorize -mthumb-interwork
>> -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 " LOCALVERSION=""
>> arm-angstrom-linux-gnueabi-gcc
>> -I/home/bbcross/rootfs/usr/include/xenomai/ -D_GNU_SOURCE -D_REENTRANT
>> -D__XENO__ -L/home/bbcross/rootfs/usr/lib -lxenomai -lnative
>> trivial-periodic.c -o trivial-periodic
>

> Could you try to run the latency test without xeno-test ?

Seams like it does not work in the similar way:

# latency -t 0
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
latency: failed to create latency task, code -1
warming up...

and then it exits. -t 1 and -t 2 works fine.

> It should be -lnative -lxenomai

Changing to -lnative -lxenomai does not help

> please use the xeno-config to obtain the flags, do not hardcode them.

I am cross-compiling and I did not figured out yet how to convince
xeno-config to pick right include and library directories. It generats
-I/usr/include and -L/usr/lib which is not where actual libraries for
cross-compilation are.

Thank you,
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

On 11/03/2012 07:42 PM, Andrey Nechypurenko wrote:

> On 3 November 2012 15:09, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>>
>> Andrey Nechypurenko wrote:
>>>> Ok, but there is no code in xenomai which accesses or relies on the
>>>> console
>>>> could you try to run the latency test from the ssh console to see if you
>>>> get the same issue?
>>>
>>> xeno-test works just fine. So I assume that it is related to how I am
>>> compiling the example. I've tried trivial-periodic.c using the
>>> following command to compile:
>>>
>>> ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- CFLAGS="
>>> -march=armv7-a -fno-tree-vectorize -mthumb-interwork
>>> -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 " LOCALVERSION=""
>>> arm-angstrom-linux-gnueabi-gcc
>>> -I/home/bbcross/rootfs/usr/include/xenomai/ -D_GNU_SOURCE -D_REENTRANT
>>> -D__XENO__ -L/home/bbcross/rootfs/usr/lib -lxenomai -lnative
>>> trivial-periodic.c -o trivial-periodic
>>
> 
>> Could you try to run the latency test without xeno-test ?
> 
> Seams like it does not work in the similar way:
> 
> # latency -t 0
> == Sampling period: 1000 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> latency: failed to create latency task, code -1
> warming up...
> 
> and then it exits. -t 1 and -t 2 works fine.
> 
>> It should be -lnative -lxenomai
> 
> Changing to -lnative -lxenomai does not help
> 
>> please use the xeno-config to obtain the flags, do not hardcode them.
> 
> I am cross-compiling and I did not figured out yet how to convince
> xeno-config to pick right include and library directories. It generats
> -I/usr/include and -L/usr/lib which is not where actual libraries for
> cross-compilation are.


Use the DESTDIR environment variable (you can look inside xeno-config to
see how it works, it should be pretty obvious).


-- 
                                                                Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

> Use the DESTDIR environment variable (you can look inside xeno-config to
> see how it works, it should be pretty obvious).

Thanks for the hint. I'll definitely try. However I doubt that it
would solve the issue with rt_task_create() since I were actually
copy-pasting the output from xeno-config and only change the -I and -L
flags to reflect my directory structure.

Thanks,
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

On 11/03/2012 10:32 PM, Andrey Nechypurenko wrote:

>> Use the DESTDIR environment variable (you can look inside xeno-config to
>> see how it works, it should be pretty obvious).
> 
> Thanks for the hint. I'll definitely try. However I doubt that it
> would solve the issue with rt_task_create() since I were actually
> copy-pasting the output from xeno-config and only change the -I and -L
> flags to reflect my directory structure.


Yes, I also doubt that very much. What about the arm/thumb issue?

-- 
                                                                Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

On 3 November 2012 22:34, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 11/03/2012 10:32 PM, Andrey Nechypurenko wrote:
>
>>> Use the DESTDIR environment variable (you can look inside xeno-config to
>>> see how it works, it should be pretty obvious).
>>
>> Thanks for the hint. I'll definitely try. However I doubt that it
>> would solve the issue with rt_task_create() since I were actually
>> copy-pasting the output from xeno-config and only change the -I and -L
>> flags to reflect my directory structure.
>
>
> Yes, I also doubt that very much. What about the arm/thumb issue?

I've run strace and found the following line in the output when
starting the programm over ssh:
sched_setscheduler(440, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not permitted)
I assume, that this call is the part of rt_task_create(). In contrast,
the same call gets no errors if running in the serial console. Really
strange to me.

My attempts to change corresponding priorities with ulimit command or
setrlimit() function does not solve the issue. So it seams like ssh
server limits some permissions somehow which causes rt_task_create()
to fail.

--
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

On 11/04/2012 05:13 PM, Andrey Nechypurenko wrote:

> On 3 November 2012 22:34, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 11/03/2012 10:32 PM, Andrey Nechypurenko wrote:
>>
>>>> Use the DESTDIR environment variable (you can look inside xeno-config to
>>>> see how it works, it should be pretty obvious).
>>>
>>> Thanks for the hint. I'll definitely try. However I doubt that it
>>> would solve the issue with rt_task_create() since I were actually
>>> copy-pasting the output from xeno-config and only change the -I and -L
>>> flags to reflect my directory structure.
>>
>>
>> Yes, I also doubt that very much. What about the arm/thumb issue?
> 
> I've run strace and found the following line in the output when
> starting the programm over ssh:
> sched_setscheduler(440, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not permitted)
> I assume, that this call is the part of rt_task_create(). In contrast,
> the same call gets no errors if running in the serial console. Really
> strange to me.
> 
> My attempts to change corresponding priorities with ulimit command or
> setrlimit() function does not solve the issue. So it seams like ssh
> server limits some permissions somehow which causes rt_task_create()
> to fail.


Did you check if your compiler compiles thumb code or arm code by default?
-- 
                                                                Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

On 11/04/2012 05:13 PM, Andrey Nechypurenko wrote:

> On 3 November 2012 22:34, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 11/03/2012 10:32 PM, Andrey Nechypurenko wrote:
>>
>>>> Use the DESTDIR environment variable (you can look inside xeno-config to
>>>> see how it works, it should be pretty obvious).
>>>
>>> Thanks for the hint. I'll definitely try. However I doubt that it
>>> would solve the issue with rt_task_create() since I were actually
>>> copy-pasting the output from xeno-config and only change the -I and -L
>>> flags to reflect my directory structure.
>>
>>
>> Yes, I also doubt that very much. What about the arm/thumb issue?
> 
> I've run strace and found the following line in the output when
> starting the programm over ssh:
> sched_setscheduler(440, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not permitted)
> I assume, that this call is the part of rt_task_create(). In contrast,
> the same call gets no errors if running in the serial console. Really
> strange to me.
> 
> My attempts to change corresponding priorities with ulimit command or
> setrlimit() function does not solve the issue. So it seams like ssh
> server limits some permissions somehow which causes rt_task_create()
> to fail.


You can run ulimit to check the current limits.
And it would be interesting to run the "whoami" command or use getuid()
in the program to check whether you are really running as the root user.

-- 
                                                                Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

On 4 November 2012 17:30, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 11/04/2012 05:13 PM, Andrey Nechypurenko wrote:
>
>> On 3 November 2012 22:34, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On 11/03/2012 10:32 PM, Andrey Nechypurenko wrote:
>>>
>>>>> Use the DESTDIR environment variable (you can look inside xeno-config to
>>>>> see how it works, it should be pretty obvious).
>>>>
>>>> Thanks for the hint. I'll definitely try. However I doubt that it
>>>> would solve the issue with rt_task_create() since I were actually
>>>> copy-pasting the output from xeno-config and only change the -I and -L
>>>> flags to reflect my directory structure.
>>>
>>>
>>> Yes, I also doubt that very much. What about the arm/thumb issue?
>>
>> I've run strace and found the following line in the output when
>> starting the programm over ssh:
>> sched_setscheduler(440, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not permitted)
>> I assume, that this call is the part of rt_task_create(). In contrast,
>> the same call gets no errors if running in the serial console. Really
>> strange to me.
>>
>> My attempts to change corresponding priorities with ulimit command or
>> setrlimit() function does not solve the issue. So it seams like ssh
>> server limits some permissions somehow which causes rt_task_create()
>> to fail.

> Did you check if your compiler compiles thumb code or arm code by default?

objdump says: file format elf32-littlearm
and file says: ELF 32-bit LSB executable, ARM, version 1 (SYSV)

> You can run ulimit to check the current limits.
> And it would be interesting to run the "whoami" command or use getuid()
> in the program to check whether you are really running as the root user.

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 79200
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 79200
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Running ulimit -r unlimited does not helps. I've also tried the
following code before calling rt_task_create():


  printf("User id: %i\n", getuid());
  getrlimit(RLIMIT_RTPRIO, &resource_limit);
  printf("Previous limits: soft=%lld; hard=%lld\n",
	 (long long) resource_limit.rlim_cur, (long long) resource_limit.rlim_max);
  printf("Max FIFO priority is: %i .\n Setting max limit to 99\n",
sched_get_priority_max(SCHED_FIFO));
  resource_limit.rlim_cur = 99;
  resource_limit.rlim_max = 99;
  if(0 != setrlimit(RLIMIT_RTPRIO, &resource_limit))

The output is:

User id: 0
Previous limits: soft=0; hard=0
Max FIFO priority is: 99 .
 Setting max limit to 99

setrlimit() does not return the error, but still rt_task_create()
fails. I found the following post in the internet, which might explain
the reason since I am also using systemd (Angstrom).

Question

I have a daemon that calls pthread_setschedparam() to set the thread
priority. On a system using systemd (OpenSuse 12.1), this fails,
because sched_setscheduler() returns EPERM.

>From what I understand systemd doesn’t use the permissions set in
/etc/security/limits.conf any more where I used to be able to allow
this.

How can I allow a deamon to change RT priorities when using systemd ?
Asked by Gene Vincent

Answer

First read “man systemd.exec” and next experiment with LimitRTPRIO and
LimitRTTIME or CPUSchedulingPolicy, CPUSchedulingPriority
CPUSchedulingResetOnFork in daemon service file.


--
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

> Did you check if your compiler compiles thumb code or arm code by default?

Here are my compilation options:

ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- CFLAGS="
-march=armv7-a -fno-tree-vectorize -mthumb-interwork
-mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 " LOCALVERSION=""

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

On 11/04/2012 05:48 PM, Andrey Nechypurenko wrote:

>> Did you check if your compiler compiles thumb code or arm code by default?
> 
> Here are my compilation options:
> 
> ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- CFLAGS="
> -march=armv7-a -fno-tree-vectorize -mthumb-interwork
> -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 " LOCALVERSION=""
> 


I know that. What I ask you is whether the toolchain you use generates
thumb code by default or not. If you want to force arm code, pass -marm
(I already said that in my first answer).


-- 
                                                                Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

On 11/04/2012 05:43 PM, Andrey Nechypurenko wrote:

> On 4 November 2012 17:30, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 11/04/2012 05:13 PM, Andrey Nechypurenko wrote:
>>
>>> On 3 November 2012 22:34, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> On 11/03/2012 10:32 PM, Andrey Nechypurenko wrote:
>>>>
>>>>>> Use the DESTDIR environment variable (you can look inside xeno-config to
>>>>>> see how it works, it should be pretty obvious).
>>>>>
>>>>> Thanks for the hint. I'll definitely try. However I doubt that it
>>>>> would solve the issue with rt_task_create() since I were actually
>>>>> copy-pasting the output from xeno-config and only change the -I and -L
>>>>> flags to reflect my directory structure.
>>>>
>>>>
>>>> Yes, I also doubt that very much. What about the arm/thumb issue?
>>>
>>> I've run strace and found the following line in the output when
>>> starting the programm over ssh:
>>> sched_setscheduler(440, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not permitted)
>>> I assume, that this call is the part of rt_task_create(). In contrast,
>>> the same call gets no errors if running in the serial console. Really
>>> strange to me.
>>>
>>> My attempts to change corresponding priorities with ulimit command or
>>> setrlimit() function does not solve the issue. So it seams like ssh
>>> server limits some permissions somehow which causes rt_task_create()
>>> to fail.
> 
>> Did you check if your compiler compiles thumb code or arm code by default?
> 
> objdump says: file format elf32-littlearm
> and file says: ELF 32-bit LSB executable, ARM, version 1 (SYSV)


The result is the same with thumb code. In order to know if a binary is
thumb or arm, run objdump and check if the binary contains 16 bits
instructions.

> 
>> You can run ulimit to check the current limits.
>> And it would be interesting to run the "whoami" command or use getuid()
>> in the program to check whether you are really running as the root user.
> 
> $ ulimit -a


What about whoami or id (it would be nice if did not have to ask the
same questions 3 times)?

I have 0 for scheduling priority and real-time priority, and it does not
seem to cause any issue.

-- 
                                                                Gilles.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

On 4 November 2012 18:05, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 11/04/2012 05:43 PM, Andrey Nechypurenko wrote:
>
>> On 4 November 2012 17:30, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On 11/04/2012 05:13 PM, Andrey Nechypurenko wrote:
>>>
>>>> On 3 November 2012 22:34, Gilles Chanteperdrix
>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>> On 11/03/2012 10:32 PM, Andrey Nechypurenko wrote:
>>>>>
>>>>>>> Use the DESTDIR environment variable (you can look inside xeno-config to
>>>>>>> see how it works, it should be pretty obvious).
>>>>>>
>>>>>> Thanks for the hint. I'll definitely try. However I doubt that it
>>>>>> would solve the issue with rt_task_create() since I were actually
>>>>>> copy-pasting the output from xeno-config and only change the -I and -L
>>>>>> flags to reflect my directory structure.
>>>>>
>>>>>
>>>>> Yes, I also doubt that very much. What about the arm/thumb issue?
>>>>
>>>> I've run strace and found the following line in the output when
>>>> starting the programm over ssh:
>>>> sched_setscheduler(440, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not permitted)
>>>> I assume, that this call is the part of rt_task_create(). In contrast,
>>>> the same call gets no errors if running in the serial console. Really
>>>> strange to me.
>>>>
>>>> My attempts to change corresponding priorities with ulimit command or
>>>> setrlimit() function does not solve the issue. So it seams like ssh
>>>> server limits some permissions somehow which causes rt_task_create()
>>>> to fail.
>>
>>> Did you check if your compiler compiles thumb code or arm code by default?
>>
>> objdump says: file format elf32-littlearm
>> and file says: ELF 32-bit LSB executable, ARM, version 1 (SYSV)
>
>
> The result is the same with thumb code. In order to know if a binary is
> thumb or arm, run objdump and check if the binary contains 16 bits
> instructions.
>
>>
>>> You can run ulimit to check the current limits.
>>> And it would be interesting to run the "whoami" command or use getuid()
>>> in the program to check whether you are really running as the root user.
>>
>> $ ulimit -a
>
>
> What about whoami or id (it would be nice if did not have to ask the
> same questions 3 times)?

>From my *previous* post:

printf("User id: %i\n", getuid()); <<<<<<<<< ist it what you were asking for?
  getrlimit(RLIMIT_RTPRIO, &resource_limit);
  printf("Previous limits: soft=%lld; hard=%lld\n",
         (long long) resource_limit.rlim_cur, (long long)
resource_limit.rlim_max);

The output is:

User id: 0 <<<<<<<<<<<<<<<<<<<<< ist it what you were asking for?
Previous limits: soft=0; hard=0
Max FIFO priority is: 99 .
 Setting max limit to 99

As I found here: https://bugzilla.redhat.com/show_bug.cgi?id=655321
----
In the meantime, you can avoid the problem by disabling the cpu cgroup
from /etc/systemd/system.conf. That is, change
#DefaultControllers=cpu
into
DefaultControllers=
----

Changing systemd.conf as suggested above solved the problem.

I am running
# systemctl --version
systemd 44
angstrom
+PAM +LIBWRAP -AUDIT -SELINUX +IMA +SYSVINIT -LIBCRYPTSETUP


Thanks,
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Andrey Nechypurenko]

> The result is the same with thumb code. In order to know if a binary is
> thumb or arm, run objdump and check if the binary contains 16 bits
> instructions.

Seams like there are no 16 bits instructions. I've also recompiled the
binary with -marm and it behaves in the same way. So the only thing
which allows the program to run from ssh console was the change in
systemd.config file I mentioned in my previous post.

I know very little about systemd configuration, so probably it is not
the best solution but it works for me.

--
Andrey.

Re: [Xenomai] rt_task_create fails when running over ssh

[Gilles Chanteperdrix]

On 11/04/2012 06:14 PM, Andrey Nechypurenko wrote:

> On 4 November 2012 18:05, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 11/04/2012 05:43 PM, Andrey Nechypurenko wrote:
>>
>>> On 4 November 2012 17:30, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> On 11/04/2012 05:13 PM, Andrey Nechypurenko wrote:
>>>>
>>>>> On 3 November 2012 22:34, Gilles Chanteperdrix
>>>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>>>> On 11/03/2012 10:32 PM, Andrey Nechypurenko wrote:
>>>>>>
>>>>>>>> Use the DESTDIR environment variable (you can look inside xeno-config to
>>>>>>>> see how it works, it should be pretty obvious).
>>>>>>>
>>>>>>> Thanks for the hint. I'll definitely try. However I doubt that it
>>>>>>> would solve the issue with rt_task_create() since I were actually
>>>>>>> copy-pasting the output from xeno-config and only change the -I and -L
>>>>>>> flags to reflect my directory structure.
>>>>>>
>>>>>>
>>>>>> Yes, I also doubt that very much. What about the arm/thumb issue?
>>>>>
>>>>> I've run strace and found the following line in the output when
>>>>> starting the programm over ssh:
>>>>> sched_setscheduler(440, SCHED_FIFO, { 99 }) = -1 EPERM (Operation not permitted)
>>>>> I assume, that this call is the part of rt_task_create(). In contrast,
>>>>> the same call gets no errors if running in the serial console. Really
>>>>> strange to me.
>>>>>
>>>>> My attempts to change corresponding priorities with ulimit command or
>>>>> setrlimit() function does not solve the issue. So it seams like ssh
>>>>> server limits some permissions somehow which causes rt_task_create()
>>>>> to fail.
>>>
>>>> Did you check if your compiler compiles thumb code or arm code by default?
>>>
>>> objdump says: file format elf32-littlearm
>>> and file says: ELF 32-bit LSB executable, ARM, version 1 (SYSV)
>>
>>
>> The result is the same with thumb code. In order to know if a binary is
>> thumb or arm, run objdump and check if the binary contains 16 bits
>> instructions.
>>
>>>
>>>> You can run ulimit to check the current limits.
>>>> And it would be interesting to run the "whoami" command or use getuid()
>>>> in the program to check whether you are really running as the root user.
>>>
>>> $ ulimit -a
>>
>>
>> What about whoami or id (it would be nice if did not have to ask the
>> same questions 3 times)?
> 
> From my *previous* post:
> 
> printf("User id: %i\n", getuid()); <<<<<<<<< ist it what you were asking for?
>   getrlimit(RLIMIT_RTPRIO, &resource_limit);
>   printf("Previous limits: soft=%lld; hard=%lld\n",
>          (long long) resource_limit.rlim_cur, (long long)
> resource_limit.rlim_max);
> 
> The output is:
> 
> User id: 0 <<<<<<<<<<<<<<<<<<<<< ist it what you were asking for?
> Previous limits: soft=0; hard=0
> Max FIFO priority is: 99 .
>  Setting max limit to 99


Yes, in an obfuscated way.

> 
> As I found here: https://bugzilla.redhat.com/show_bug.cgi?id=655321
> ----
> In the meantime, you can avoid the problem by disabling the cpu cgroup
> from /etc/systemd/system.conf. That is, change
> #DefaultControllers=cpu
> into
> DefaultControllers=
> ----
> 
> Changing systemd.conf as suggested above solved the problem.


Fine.

-- 
                                                                Gilles.