EPICS Controls Argonne National Laboratory

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  <20152016  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  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: caPutLog problem solved
From: "Qiao Yusi" <[email protected]>
To: [email protected]
Date: Wed, 25 Nov 2015 10:44:43 +0800 (GMT+08:00)
Thanks a lot! After changing the caPutLogInit port 7004, it works successfully. And thank you for providing information about iocLogSev2.  


> -----原始邮件-----
> 发件人: [email protected]
> 发送时间: 2015年11月25日 星期三
> 收件人: [email protected]
> 抄送: 
> 主题: Tech-talk Digest, Vol 9, Issue 366
> 
> Send Tech-talk mailing list submissions to
> 	[email protected]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
> or, via email, send a message with subject or body 'help' to
> 	[email protected]
> 
> You can reach the person managing the list at
> 	[email protected]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tech-talk digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Successfully locked memory using mlockAll (Henrique Almeida)
>    2. Re: Missaligned protocol rejected when using caPutLog
>       (Michael Davidsaver)
>    3. Re: error: ?dbChannel? has no member named ?final_dbr_type?
>       (Henrique Almeida)
>    4. Re: error: ?dbChannel? has no member named ?final_dbr_type?
>       (Pete Jemian)
>    5. RE: error: ?dbChannel? has no member named ?final_dbr_type?
>       (Mark Rivers)
>    6. Re: Successfully locked memory using mlockAll (Till Straumann)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 24 Nov 2015 10:22:07 -0200
> From: Henrique Almeida <[email protected]>
> To: Andrew Johnson <[email protected]>
> Cc: "[email protected] Talk" <[email protected]>
> Subject: Re: Successfully locked memory using mlockAll
> Message-ID:
> 	<CAP_Z8ckAPp6L0_mGR7CpZd4tw0_JiZYMh3rhe6cNVPnzf+DPSQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
>  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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.aps.anl.gov/pipermail/tech-talk/attachments/20151124/d87cd805/attachment.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 24 Nov 2015 08:44:02 -0500
> From: Michael Davidsaver <[email protected]>
> To: [email protected]
> Subject: Re: Missaligned protocol rejected when using caPutLog
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8
> 
> The CA server is complaining because caPutLog speaks a different protocol and requires a different server.  caPutLogInit should never be given port 5064.
> 
> You should investigate the iocLogServer executable which is built as part of epics base which speaks the protocol used by caputlog.  By default this listens on port 7004.  This is designed to act as a central log server for many IOCs.
> 
> I also have https://github.com/mdavidsaver/ioclogserv2 with some additional features including better log file rotation behavior.
> 
> 
> On 11/24/2015 04:49 AM, Qiao Yusi wrote:
> > Hi, everyone:
> > 
> >  
> > 
> > I?m a newbie at EPICS. I have some trouble running caPutLog on RedHat Linux. When using caput to change a pv value, here came:
> > 
> > epics> CAS: request from 192.168.206.74:32975 => "CAS: Missaligned protocol rejected"
> > 
> > CAS: Request from 192.168.206.74:32975 => cmmd=12852 cid=0x35203131 type=28534 count=11569 postsize=11598
> > 
> > CAS: Request from 192.168.206.74:32975 =>  available=0x3a34323a         N=0 paddr=(nil)
> > 
> > CAS: forcing disconnect from 192.168.206.74:32975
> > 
> > So my logfile can only log the error.
> > 
> > The IOC is running on epics-base 3.14.12.1, and the caPutLog version is 3.4.
> > 
> > My server and client are on the same host, and here are some related environment variables, the host IP is 192.168.206.74:
> > 
> > export EPICS_CA_AUTO_ADDR_LIST=NO
> > 
> > export EPICS_CA_ADDR_LIST=192.168.206.74
> > 
> > export EPICS_IOC_LOG_INET=192.168.206.74
> > 
> > export EPICS_IOC_LOG_PORT=7004
> > 
> > export EPICS_IOC_LOG_FILE_NAME=/home/qys/save/logfile
> > 
> >  
> > 
> > I can?t figure out what is wrong. Hope someone can help me. Thanks!
> > 
> > (More details please see the attachment.)
> > 
> > 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 24 Nov 2015 12:58:31 -0200
> From: Henrique Almeida <[email protected]>
> To: Mark Rivers <[email protected]>
> Cc: "[email protected] Talk" <[email protected]>
> Subject: Re: error: ?dbChannel? has no member named ?final_dbr_type?
> Message-ID:
> 	<CAP_Z8cm7+7C4qcdQDy6oS18nE=tZVYJ+1edJ03g9pDUL95vOnw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
>  Mark, I can confirm that replacing the caputRecorder in synApps 5.8 with
> the github master branch solved the problem. However, my plan was using an
> unmodified synApps version. You said that the latest version of each module
> works with the latest version of all other modules. But synApps itself is
> not working with the latest EPICS base version. Since EPICS base 3.15.2 was
> released in May, then this rule has been broken for synApps for the last 6
> months. Maybe it's time to release synApps 5.9 ?
> 
> 
> 2015-11-23 18:15 GMT-02:00 Mark Rivers <[email protected]>:
> 
> > You can now find the latest versions of all the synApps modules in
> > https://github.com/epics-modules.
> >
> > There have been 3 releases of caputRecorder since synApps 5.8.
> >
> > Generally the latest tagged version of each module will work with the
> > latest tagged version of all other modules.
> >
> > I am using the latest version of all synApps modules now with no problems.
> >
> > Mark
> >
> >
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > On Behalf Of Henrique Dante de Almeida
> > Sent: Monday, November 23, 2015 2:02 PM
> > To: [email protected] Talk
> > Subject: error: ?dbChannel? has no member named ?final_dbr_type?
> >
> >
> >
> >  Hello, I'm building synApps 5.8 on a fresh Red Hat 6.6 install and I'm
> > receiving the following error:
> >
> > /usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE            -D_X86_  -DUNIX
> > -Dlinux     -O3 -g   -Wall      -mtune=generic     -m32
> > -D_FILE_OFFSET_BITS=64 -fPIC -I. -I../O.Common -I. -I. -I..
> > -I../../../include/compiler/gcc -I../../../include/os/Linux
> > -I../../../include -I/usr/local/epics/base-3.15.2/include/compiler/gcc
> > -I/usr/local/epics/base-3.15.2/include/os/Linux
> > -I/usr/local/epics/base-3.15.2/include        -c ../caputRecorder.c
> > ../caputRecorder.c: In function ?myAsDataListener?:
> > ../caputRecorder.c:283: error: ?dbChannel? has no member named
> > ?final_dbr_type?
> >
> > (etc.)
> >
> >  It seems that there exists a patch for this problem:
> >
> > https://subversion.xor.aps.anl.gov/trac/synApps/changeset/19339
> >
> >  Are there plans for merging this patch in synApps ? What about a new
> > synApps release ?
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.aps.anl.gov/pipermail/tech-talk/attachments/20151124/b6d159f0/attachment.html>
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 24 Nov 2015 09:52:25 -0600
> From: Pete Jemian <[email protected]>
> To: <[email protected]>
> Subject: Re: error: ?dbChannel? has no member named ?final_dbr_type?
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"; format=flowed
> 
> 
> Henrique:
> 
> thanks for your suggestion.
> 
> We will look at what compels the next release of synApps.  IMO, this 
> change, by itself, is not sufficient to justify the work to make a new 
> release.
> 
> Until we make a new synApps release, you can install new releases of any 
> module(s) alongside the existing modules in the support directory.  Such as:
> 
> support/
>     ...
>     caputRecorder
>     caputRecorder_1-5-1
>     ...
> 
> Then, update the configure/RELEASE file with the new module path(s), 
> then do a rebuild in the support directory:
> 
> make release
> make
> 
> This leaves you in a position to revert to a pristine synApps 5.8 
> configuration, should you so require.
> 
> Pete
> 
> On 11/24/2015 8:58 AM, Henrique Almeida wrote:
> >
> >   Mark, I can confirm that replacing the caputRecorder in synApps 5.8
> > with the github master branch solved the problem. However, my plan was
> > using an unmodified synApps version. You said that the latest version of
> > each module works with the latest version of all other modules. But
> > synApps itself is not working with the latest EPICS base version. Since
> > EPICS base 3.15.2 was released in May, then this rule has been broken
> > for synApps for the last 6 months. Maybe it's time to release synApps 5.9 ?
> >
> >
> > 2015-11-23 18:15 GMT-02:00 Mark Rivers <[email protected]
> > <mailto:[email protected]>>:
> >
> >     You can now find the latest versions of all the synApps modules in
> >     https://github.com/epics-modules.
> >
> >     There have been 3 releases of caputRecorder since synApps 5.8.
> >
> >     Generally the latest tagged version of each module will work with
> >     the latest tagged version of all other modules.
> >
> >     I am using the latest version of all synApps modules now with no
> >     problems.
> >
> >     Mark
> >
> >
> >
> >     -----Original Message-----
> >     From: [email protected]
> >     <mailto:[email protected]>
> >     [mailto:[email protected]
> >     <mailto:[email protected]>] On Behalf Of Henrique Dante
> >     de Almeida
> >     Sent: Monday, November 23, 2015 2:02 PM
> >     To: [email protected] <mailto:[email protected]> Talk
> >     Subject: error: ?dbChannel? has no member named ?final_dbr_type?
> >
> >
> >
> >       Hello, I'm building synApps 5.8 on a fresh Red Hat 6.6 install and
> >     I'm receiving the following error:
> >
> >     /usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE            -D_X86_
> >     -DUNIX  -Dlinux     -O3 -g   -Wall      -mtune=generic     -m32
> >     -D_FILE_OFFSET_BITS=64 -fPIC -I. -I../O.Common -I. -I. -I..
> >     -I../../../include/compiler/gcc -I../../../include/os/Linux
> >     -I../../../include
> >     -I/usr/local/epics/base-3.15.2/include/compiler/gcc
> >     -I/usr/local/epics/base-3.15.2/include/os/Linux
> >     -I/usr/local/epics/base-3.15.2/include        -c ../caputRecorder.c
> >     ../caputRecorder.c: In function ?myAsDataListener?:
> >     ../caputRecorder.c:283: error: ?dbChannel? has no member named
> >     ?final_dbr_type?
> >
> >     (etc.)
> >
> >       It seems that there exists a patch for this problem:
> >
> >     https://subversion.xor.aps.anl.gov/trac/synApps/changeset/19339
> >
> >       Are there plans for merging this patch in synApps ? What about a
> >     new synApps release ?
> >
> >
> 
> -- 
> ----------------------------------------------------------
> Pete R. Jemian, Ph.D.                <[email protected]>
> Beam line Controls and Data Acquisition, Group Leader
> Advanced Photon Source,   Argonne National Laboratory
> Argonne, IL  60439                   630 - 252 - 3189
> -----------------------------------------------------------
>     Education is the one thing for which people
>        are willing to pay yet not receive.
> -----------------------------------------------------------
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 24 Nov 2015 16:08:25 +0000
> From: Mark Rivers <[email protected]>
> To: "'Henrique Almeida'" <[email protected]>
> Cc: "[email protected] Talk" <[email protected]>
> Subject: RE: error: ?dbChannel? has no member named ?final_dbr_type?
> Message-ID:
> 	<70AE7462E7AD054C89DCBA45343D499A65A0B43A@CARSMAIL2.CARS.APS.ANL.GOV>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Henrique,
> 
> Personally I don?t find the concept of synApps releases very useful.  Every official synApps release has significant bugs and build problems, and is almost instantly out of date because it lacks major new features of one or more support modules.  In my 20+ years of running synApps on our beamlines and labs I have never been able to run an official synApps release.
> 
> For example, in the 11 months since synApps 5-8 was released the following synApps modules have had a total of 27 new tagged releases:
> 
> alive: 1-0-1
> areaDetector/ADCore: 2-2, 2-3, 2-4
> asyn: 4-26, 4-27
> autosave: 5-6-2, 5-7, 5-7-1
> calc: 3-5, 3-6, 3-6-1
> caputRecorder: 1-4-3, 1-5, 1-5-1
> dxp: 3-5
> iocStats: 3.1.14
> ip: 2-10
> optics: 2-10, 2-11
> softGlue: 2-5, 2-6, 2-7
> sscan: 2-10-2
> stream: 2-6b, 2-6c
> xxx: 5-8-4
> 
> Each of these releases either fixes significant bugs, adds significant new features, or both.  At what point should a new synApps release be made?  It will clearly be obsolete in less than 2 weeks on average, since there are 27 releases of synApps modules in less than 1 year.
> 
> I would find it much more helpful if rather than official synApps releases there were simply a list of known incompatibilities of the latest release of module X with the latest tagged release of module Y.
> 
> Mark
> 
> 
> 
> From: Henrique Almeida [mailto:[email protected]]
> Sent: Tuesday, November 24, 2015 8:59 AM
> To: Mark Rivers
> Cc: Henrique Dante de Almeida; [email protected] Talk
> Subject: Re: error: ?dbChannel? has no member named ?final_dbr_type?
> 
> 
>  Mark, I can confirm that replacing the caputRecorder in synApps 5.8 with the github master branch solved the problem. However, my plan was using an unmodified synApps version. You said that the latest version of each module works with the latest version of all other modules. But synApps itself is not working with the latest EPICS base version. Since EPICS base 3.15.2 was released in May, then this rule has been broken for synApps for the last 6 months. Maybe it's time to release synApps 5.9 ?
> 
> 
> 2015-11-23 18:15 GMT-02:00 Mark Rivers <[email protected]<mailto:[email protected]>>:
> You can now find the latest versions of all the synApps modules in https://github.com/epics-modules.
> 
> There have been 3 releases of caputRecorder since synApps 5.8.
> 
> Generally the latest tagged version of each module will work with the latest tagged version of all other modules.
> 
> I am using the latest version of all synApps modules now with no problems.
> 
> Mark
> 
> 
> 
> -----Original Message-----
> From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Henrique Dante de Almeida
> Sent: Monday, November 23, 2015 2:02 PM
> To: [email protected]<mailto:[email protected]> Talk
> Subject: error: ?dbChannel? has no member named ?final_dbr_type?
> 
> 
> 
>  Hello, I'm building synApps 5.8 on a fresh Red Hat 6.6 install and I'm receiving the following error:
> 
> /usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE            -D_X86_  -DUNIX  -Dlinux     -O3 -g   -Wall      -mtune=generic     -m32 -D_FILE_OFFSET_BITS=64 -fPIC -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/gcc -I../../../include/os/Linux -I../../../include -I/usr/local/epics/base-3.15.2/include/compiler/gcc -I/usr/local/epics/base-3.15.2/include/os/Linux -I/usr/local/epics/base-3.15.2/include        -c ../caputRecorder.c
> ../caputRecorder.c: In function ?myAsDataListener?:
> ../caputRecorder.c:283: error: ?dbChannel? has no member named ?final_dbr_type?
> 
> (etc.)
> 
>  It seems that there exists a patch for this problem:
> 
> https://subversion.xor.aps.anl.gov/trac/synApps/changeset/19339
> 
>  Are there plans for merging this patch in synApps ? What about a new synApps release ?
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.aps.anl.gov/pipermail/tech-talk/attachments/20151124/131f635c/attachment.html>
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 24 Nov 2015 08:23:26 -0800
> From: Till Straumann <[email protected]>
> To: Henrique Almeida <[email protected]>, Andrew Johnson
> 	<[email protected]>
> Cc: "[email protected] Talk" <[email protected]>
> Subject: Re: Successfully locked memory using mlockAll
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> 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] 
> > <mailto:[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
> >     <https://code.launchpad.net/%7Emshankar/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
> >
> >
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.aps.anl.gov/pipermail/tech-talk/attachments/20151124/f3a669d1/attachment.html>
> 
> ------------------------------
> 
> _______________________________________________
> Tech-talk mailing list [email protected]
> https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
> 
> 
> End of Tech-talk Digest, Vol 9, Issue 366
> *****************************************



Replies:
Re: caPutLog problem solved Benjamin Franksen

Navigate by Date:
Prev: Re: error: ‘dbChannel’ has no member named ‘final_dbr_type’ Michael Davidsaver
Next: Device Support for I2C and GPIO Florian Feldbauer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Missaligned protocol rejected when using caPutLog Michael Davidsaver
Next: Re: caPutLog problem solved Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·