Experimental Physics and
Industrial Control System

1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024	Index	1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024
<== Date ==>		<== Thread ==>

Subject:	Re: Successfully locked memory using mlockAll
From:	Till Straumann <[email protected]>
To:	Henrique Almeida <[email protected]>, Andrew Johnson <[email protected]>
Cc:	"[email protected] Talk" <[email protected]>
Date:	Tue, 24 Nov 2015 08:23:26 -0800

It has indeed nothing to do whether you execute as root or not
but depends on whether EPICS has the sufficient privilege to use
the real-time scheduler.
In many cases use of this scheduler is restricted but obviously
root always has sufficient privilege and such systems (without
additional measures) the simple formula is: executed as 'root'
EPICS will use the RT scheduler, executed as a normal user it won't.

We configure our real-time systems usually so that the user account
which starts EPICS IOCs does indeed have the privilege to use
the RT-scheduler. We do this by granting an unlimited hard boundary
for real-time priorities (setrlimit(RLIMIT_RTPRIO) or 'ulimit' from bash).
However, we also set the initial soft limit to zero.

This setup means that by default the user's EPICS (and other processes)
cannot use the RT scheduler (since the soft limit is 0).

If the user wants to spawn an RT process then they lift the soft limit

bash$ ulimit -S -r unlimited

and likewise for the amount of locked memory:

bash$ ulimit -S -l unlimited

Subsequently started processes can then use these resources which are
critical for real-time performance.

I don't know the setup of your system but you could simply try

ulimit -S -r 0

and then your EPICS clients (and other processes) should not
be able to use the RT scheduler (and will not try to mlockall).

The rationale behind all of this is that
- since EPICS has the potential to operate as a real-time application
   it will try to do so if you let it (= if it determines it has sufficient privilege)
   assuming that was your intention
- real-time execution requires all real-time critical data, stack and text to
   permanently reside in memory. Since it would put a significant burden on
   the programmer to manually identify all critical memory areas and
   selectively lock these the complete process is locked in memory.
   We have diskless system here with 1G of RAM and there haven't been
   real issues with lack of memory.
- if EPICS determines it has not sufficient privilege to use the RT scheduler
   then it falls back on the vanilla scheduler and will not attempt to lock
   the process in memory.

I can also recommend to read this wiki page

https://wiki-ext.aps.anl.gov/epics/index.php/How_To_Use_Posix_Thread_Priority_Scheduling_under_Linux

HTH
- Till

On 11/24/2015 04:22 AM, Henrique Almeida wrote:

Hello, but these messages may appear to non root users, and are not really related to being root or not, but to the real time operations in libCom. For example:

[henrique.almeida@SOL1-HOST1 linux-x86]$ cp caget /tmp/

[henrique.almeida@SOL1-HOST1 linux-x86]$ cd /tmp/

[henrique.almeida@SOL1-HOST1 tmp]$ sudo setcap 'cap_sys_nice+ep cap_ipc_lock+ep' ./caget

[henrique.almeida@SOL1-HOST1 tmp]$ ./caget LNLS:ANEL:corrente

Successfully locked memory using mlockAll

LNLS:ANEL:corrente 227.682

In the example above, standard non-root user saw the debug message even though he's not root, only because I activated real time support.

This looks like a design bug to me, because a helper library is writing on the standard error on behalf of the application when it was not asked for doing it. Can this feature be disabled ?

2015-11-23 19:44 GMT-02:00 Andrew Johnson <[email protected]>:

Hi,

On 11/23/2015 01:20 PM, Henrique Dante de Almeida wrote:
>
> Hello, I'm testing EPICS base v 3.15 on a fresh Red Hat 6.6
> installation and after compiling, executing caget always returns
> the message "Successfully locked memory using mlockAll":
>
> [root@SOL1-HOST1 linux-x86]# ./caget LNLS:ANEL:corrente
> Successfully locked memory using mlockAll
> Successfully locked memory using mlockAll
> LNLS:ANEL:corrente 161.585
> [root@SOL1-HOST1 linux-x86]# cd
> [root@SOL1-HOST1 ~]# caget LNLS:ANEL:corrente
> Successfully locked memory using mlockAll
> LNLS:ANEL:corrente 161.553
> [root@SOL1-HOST1 ~]# caget LNLS:ANEL:corrente
> Successfully locked memory using mlockAll
> LNLS:ANEL:corrente 161.553
> (etc.)
>
> Can the message be removed ? Here is what seems to be the relevant
> commit:
>
> https://code.launchpad.net/~mshankar/epics-base/memlock_linux/+merge/232466

Those messages will be printed to stderr if you run caget (or any other
program linked with our libCom library) as root. Using the root account
to run programs that don't need such privilege is a bad idea from a
computer security perspective though. Some sites do need to run certain
IOCs with root privilege to enable the real-time scheduler (which then
makes it desirable to lock the IOC code into physical RAM) or to access
certain I/O hardware from user-space, but in most cases we'd recommend
that you use a non-root account for programs like caget/caput/camonitor.

- Andrew

--
Light thinks it travels faster than anything but it is wrong.
No matter how fast light travels, it finds the darkness has
always got there first, and is waiting for it.
-- Terry Pratchett, Reaper Man

References:: Successfully locked memory using mlockAll Henrique Dante de Almeida; Re: Successfully locked memory using mlockAll Andrew Johnson; Re: Successfully locked memory using mlockAll Henrique Almeida

Navigate by Date:: Prev: RE: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Mark Rivers; Next: RE: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Mooney, Tim M.; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024
Navigate by Thread:: Prev: Re: Successfully locked memory using mlockAll Henrique Almeida; Next: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Henrique Dante de Almeida; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024

ANJ, 16 Dec 2015

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System