[systemd-devel] process change default scheduler - please help - desperate
JB
general at itpsg.com
Sun Dec 30 18:36:59 PST 2012
I'm guessing you didn't read the entire message. Please read it all.
Scheduling options do not solve my problem. The appcore program needs
to be able to call rtai_task_init to initialize a real-time task using
RTAI. I need the rights and permissions, the scheduling code and
selections is an easy way to demonstrate the problem for someone who
isn't interested in patching their kernel with the RTAI kernel patches
and invest time in an RTAI installation. Note to others, please read
the entire thread including the bit about scheduling options available
in systemd NOT solving the problem. I've practically memorized all the
systemd man pages. While I admit, I could have missed something over
the last 3 weeks of diligent study on systemd I think I've RTFM
waaaaaaay too much for anyone here to say "RTFM" with any credibility.
JB
Reindl Harald wrote:
> http://www.freedesktop.org/software/systemd/man/systemd.exec.html
> there are a lot of Scheduling options
>
> Am 31.12.2012 02:50, schrieb JB:
>
>> Bottom line is I need to give a process started by systemd and any process started by that process some privileges
>> to chanage scheduler and other things when it starts. How do I tell systemd to grant these privileges to one of
>> it's services?
>>
>> Here's all the detail:
>>
>> I'm having a really frustrating problem. I have a ruby webrick daemon that starts up at boot. Previously it
>> always started from init and that always worked fine right up through fedora 8 on a 2.6.29.9 kernel. Now I'm
>> running the following:
>> OS: Fedora Core 15
>> Kernel: 2.6.38.8 64-bit with RTAI patches
>> SELinux is disabled
>>
>> I did manage to get the thing to start using the following service file:
>> *********** BEGIN webrickd.service ************
>> [Unit]
>> Description=Configuration ruby webrick daemon
>> After=network.target
>>
>> [Service]
>> Type=forking
>> WorkingDirectory=/home/rtuser/app/bin
>> PIDFile=/home/rtuser/app/data/logs/webrickd.pid
>> ExecStartPre=/home/rtuser/app/system/scripts/preStart.sh
>> ExecStart=/home/rtuser/app/bin/webrickd.rb -d -p /home/rtuser/app/data/logs/webrickd.pid
>> StandardOutput=null
>> StandardError=null
>> User=rtuser
>> Group=rtuser
>>
>> [Install]
>> WantedBy=multi-user.target
>> *********** END webrickd.service *************
>>
>> This webrick daemon upon receiving a specific web service call uses "exec" to start another process called appcore
>> which is a compiled C application. appcore runs real-time and consequently uses a call to sched_setscheduler() to
>> change it's scheduling from the default. Sample code for reproduction is below:
>>
>> *********** BEGIN appcore.c *************
>> #include <stdio.h>
>> #include <errno.h>
>> #include <sched.h>
>>
>> int main(int argc, char *argv[])
>> {
>> struct sched_param mysched;
>>
>> errno = 0;
>> mysched.sched_priority = sched_get_priority_max(SCHED_FIFO) - 1;
>> if( sched_setscheduler( 0, SCHED_FIFO, &mysched ) == -1 ) {
>> puts("appcore: ERROR IN SETTING THE SCHEDULER");
>> perror("errno");
>> return 1;
>> } // end
>> if
>>
>> return 0;
>> }
>> ************** END appcore.c **************
>>
>> compile with gcc -o appcore appcore.c
>>
>> Running the above program will work with a normally created unprivileged user account but only when logged in with
>> a PAM session using an interactive shell. As soon as I try to start this up from anything that is started by
>> systemd, it yields an "Operation not permitted" error. I realize there are other ways to specify what scheduling
>> service a process should have in the above systemd configuration file, but that does not solve my problem. Even
>> without this call, the RTAI extensions I use which use a call to rtai_task_init() also apparently require this same
>> privilege (or one like it) because it too fails with "Operation not permitted" so even if I tell systemd to give
>> the ruby webrickdaemon SCHED_FIFO priority and I can somehow get that inherited to appcore, I will still have the
>> same problem, because there is no way for systemd to create a real-time task using the RTAI extensions for me
>> before my program starts. I've tried all the following (and their combinations) without success:
>>
>> LimitCPU=infinity
>> LimitFSIZE=infinity
>> LimitDATA=infinity
>> LimitSTACK=infinity
>> LimitCORE=infinity
>> LimitRSS=infinity
>> #LimitNOFILES=infinity # using any variety of this fails no matter what
>> LimitAS=infinity
>> LimitNPROC=infinity
>> LimitMEMLOCK=infinity
>> LimitLOCKS=infinity
>> LimitSIGPENDING=infinity
>> LimitMSGQUEUE=infinity
>> LimitNICE=infinity
>> LimitRTPRIO=infinity
>> LimitRTTIME=infinity
>> CapabilityBoundingSet=~CAP_SYS_PTRACE
>> PAMName=appcore
>>
>> Modifications to /etc/security/limits.conf of course don't really help because it works fine under a shell without
>> any modifications and that stuff all gets bypassed with init processes starting even when you specify User and
>> Group. I've tried using sudo (won't even start it) to try to get a PAM session as though it were a login, I've
>> tried setuid without success, I've tried everything I can think of but absolutely everything works when run from an
>> interactive shell and absolutely nothing works, all I get is "Operation not permitted" anytime I let systemd start
>> things up. Please help! I'm desperate. I get what you're trying to do with systemd and I support it and I have
>> to say for a first release of it, it seems well designed and thought out. I'm impressed with it's flexibility.
>> However, I quite literally ***cannot find a way to make this work*** when it just "worked" before. What in the
>> world do I have to do to have systemd start this process up with whatever equivalent rights or permissions it used
>> to have with init and whatever it seems to have when run from an interactive shell.
>>
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
More information about the systemd-devel
mailing list