EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: AlarmHandler as a daemon or service
From: "Zhou, Jingchen" <[email protected]>
To: "Ernest L. Williams Jr." <[email protected]>, "EPICS tech-talk" <[email protected]>
Date: Fri, 24 Mar 2006 16:35:02 -0800
Hi Ernest,

Xvfb (Virtual Framebuffer X server) provides a X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory. The primary usage of this server was intended to be server testing; other usages include testing clients, doing batch processing with Xvfb as a background rendering engine.  We have found that Xvfb provides an excellent solution for us to run a X based application on production server machines that don't have X server on them. The application can be started at booting time as a background process and without a visible display either locally or remotely. The EPICS Alarm handle (a standalone program) used here in SLAC as Steph pointed out is a good example for such usage.

Xvfb should be a part of X11R6. If you don't have one, you can get it via 
ftp ferret.wrc.noaa.gov:
Name (ferret.wrc.noaa.gov:kobrien): anonymous
331 Guest login ok, send ident as password.
Password: your_email_address
230 Guest login ok, access restrictions apply.
ftp> cd special_request/xvfb/solaris
ftp> get X11R6.1_bin.tar.Z

To start up the virtual frame buffer, type:

% /usr/X11R6/bin/Xvfb :1 -screen 0 1152x900x8 &

Any graphics output going to display 1 will be sent to the virtual memory. 
You should add this line into a startup script in boot sequence. 

To set the current display to use the virtual framebuffer for graphics display, type:

 $ setenv DISPLAY :1.0 

Jingchen    

-----Original Message-----
From: Allison, Stephanie [mailto:[email protected]] 
Sent: Friday, March 24, 2006 8:42 AM
To: Ernest L. Williams Jr.; EPICS tech-talk
Cc: [email protected]
Subject: RE: AlarmHandler as a daemon or service

Hi Ernest,

At SPEAR, we run one "standalone" ALH which is started at system reboot.  In order to get around the need for an X terminal, it uses Xfvb (Virtual Framebuffer X Server) which is started before the standalone ALH.  The purpose of this ALH is simply to send alarms to cmlog.  It's started with these options:

To use Xfvb:
    setenv DISPLAY :1.0

#             -oCM = log operator mods to CMLOG
#             -wCM = wordy CMLOG messages
#             -aCM = log alarms to CMLOG
#             -m 2000 = max number of alarms in the alarm file
#             -s = silent
#             -S = passive
#             -noerrorpopup 
#             -l $ALHLOGFILES    = where log files are
#             -f $ALHCONFIGFILES = where config files are
#             -a Alarms.log = name of alarm log files
#             -o OpMods.log = name of op mod log files

I left the Alarms.log and OpMods.log for my own use.

(BTW - the "wordy" option was added since we wanted more information in the text).

I added a special cmlog browser to take messages from the cmlogServer as they come and send them to a server on our RDB machine that sticks them into RDB so we can see alarm events (along with events from our other clients like channelWatcher and other monitoring programs) from the web.  Maybe someday we get rid of cmlogServer and have ALH and channelWatcher log directly to the RDB server.

Works OK for us except our version of ALH is very old and has bugs which are most probably fixed in the newer version.  When I get some time, I'll upgrade.

Stephanie Allison
SPEAR/SSRL and LCLS/SLAC


Replies:
RE: AlarmHandler as a daemon or service Ernest L. Williams Jr.

Navigate by Date:
Prev: RE: AlarmHandler as a daemon or service Waggoner, Bill
Next: RE: AlarmHandler as a daemon or service Ernest L. Williams Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: AlarmHandler as a daemon or service Waggoner, Bill
Next: RE: AlarmHandler as a daemon or service Ernest L. Williams Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·