13 Jan
2007
13 Jan
'07
8:36 a.m.
Fernando Lopez-Lezcano:
On Fri, 2007-01-12 at 19:01 -0500, lanas wrote:
Except for that want-to-hog-the-cpu scenario (which is very uncommon at
least for audio usage), I would say that using either rt_watchdog or
(especially) das_watchdog is a very good solution to the above mentioned
problems. I don't know whats getting so complicated...
3) Adjusted access to priorities by adding this
to /etc/security/limits.conf:
# Added for audio
* - rtprio 99
* - nice -10
* - memlock 4000000
BTW, I read that the above is an insecure configuration. So, some
finetuning could be done with that. There's an active Fedora
Firewall, as well as SELinux, so maybe this is not as critical as it
sounds. I'd appreciate any input on this.
It all boils down to who can use programs that run with realtime
priorities and whether you trust them. The above conf (which I use)
gives access to everybody - meaning anybody can potentially hang the
machine, either through buggy software, a mistake or intentionally.
You can of course restrict things a bit more by using unix groups and
only give access to a group of users (which you presumably trust...),
then that's more "secure". Still, allowed users can hang the machine if
they want.
You could also restrict the range of priorities users can use, add a
watchdog program that runs at a higer priority and kills or downgrades
the scheduler to SCHED_OTHER of processes that are hogging the cpu - but
IMHO things get complicated too fast, and sometimes you may _want_ to
hog the cpu :-)