I'm hoping to avoid having to do the same thing (Windows env) here, that
is, build a custom aremail watchdog to kick-start the service when email
starts stacking up. Our AREMail 7.1.00.002 engine has been dying
silently and randomly for over a month now, sometimes after a java error
in the stderr.log and sometimes with no error at all. It has taken a
month to get support to escalate it, so they are dragging this out as
long as possible. It often dies in the middle of sending out a set of
standard group assignment or ownership notifications, leaving the flag
on the last message sent at Yes so that when we restart it goes out
again. When it hangs, the service does not shut down properly since the
Windows service wrapper still thinks it is running but it is not - you
get an error about response time.
Maybe it is due in part to the number of messages lying around in the
email form - I haven't had time to invent the missing data maintenance
on that form (or any others in the ITSM 7 hidden data time bomb), so it
is approaching 50K of entries already.
The occasional java error we see is a new one on me:
java.rmi.ConnectIOException: error during JRMP connection establishment;
nested exception is:
java.net.SocketException: Connection reset
at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown
Source)
at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown
Source)
at sun.rmi.server.UnicastRef.newCall(Unknown Source)
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
at java.rmi.Naming.rebind(Unknown Source)
at
com.bmc.arsys.emaildaemon.EmailDaemon.newInstance(EmailDaemon.java:180)
at
com.bmc.arsys.emaildaemon.EmailDaemon.startMonitor(EmailDaemon.java:864)
at
com.bmc.arsys.emaildaemon.EmailDaemon.executeComandLine(EmailDaemon.java
:592)
at
com.bmc.arsys.emaildaemon.EmailDaemon.main(EmailDaemon.java:313)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at java.io.DataInputStream.readByte(Unknown Source)
... 9 more
Has anyone observed more stable behavior from AREmail 7.1.00.003? I
haven't been in the office enough this month to get any of the new
patches up and running in a test/dev environment.
Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
> Sent: Tuesday, July 22, 2008 6:43 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Help with a UNIX script to STOP the AREmail daemon
>
> George,
>
> On the Unix's the script emaild.sh should get the job done to start or
> stop the email engine. ( Email-Engine-710.pdf pg 41 has details)
>
> A single run process should get the job done.
>
> <email_engine_install_dir>/emaild.sh stop
> &;<email_engine_install_dir>/emaild.sh start &;
>
> You can likely find "< email_engine_install_dir >" with this:
>
> grep emaild /etc/arsystem/< hostname >/armonitor.conf
>
>
> As far as using an ARS application to do the stop/start... well...
> here is what I would suggest..
>
> 1) Create a new form that you use data in the form to decide to run
> the Escalation and to hang filters off of so that you can have much
> more advanced logic for your Escalation processes.
>
> 2) Create a row in this new form that indicates that Escalations "X"
> should run by using a character field that you put the name of the
> escalation into and using a 'Status' = "Run" (or some other string
> that you like).
>
> 3) Create the Escalation to check this new form with a run if like
> this:
> 'ESC Name' = "X" AND 'Status' = "Run"
> Note: You may want to have a unique index on the 'ESC Name', or not,
> depending on your total needs. You could also add a date time field so
> that your Escalation could check every hour, and your date time field
> could be updated by other processing to "skip" an hour for example.
>
> 4) Have the Escalation do a SET FIELD action to the one row(s) that
> you find. This will trigger Filters on the new form in MODIFY.
>
> 5) Then write whatever logic you need in the filters.
> For this case... maybe do a set field (from a filter) for "email
> message in the queue ...with a status of SEND". If the 'Create-Date'
> for the first record returned (assuming sort order on the form would
> return the "oldest" record) is "old enough" then do a run process to
> stop and start the email engine. If the date seems to indicated that
> the Email engine is working within it' polling intervals... then do
> nothing and let the modify finish.
> You can even send notifications when the email engine is
> "restarted" or "not -restarted", as desired too.
>
> HTH.
>
> --
> Carey Matthew Black
> Remedy Skilled Professional (RSP)
> ARS = Action Request System(Remedy)
>
> Love, then teach
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
>
> On Fri, Jul 18, 2008 at 11:57 AM, Payne, George <[EMAIL PROTECTED]>
> wrote:
> > **
> >
> > Hey gang...
> >
> >
> >
> > Occasionally the ARSystem Email Engine will just stop working. The
> DAEMON
> > is running and so the ARMONITOR does not realize that the service
> needs to
> > be re-started because the PROCESS is still running.
> >
> >
> >
> > What I would like to do is have an ESCALATION run a PROCESS on the
> server to
> > KILL the AREmail process so that ARMONITOR would automatically
> restart it.
> >
> >
> >
> > One caution:
> > I don't want to run it against EVERY unsent email message in the
> queue...it
> > just needs to run against the OLDEST with a status of SEND.
> >
> >
> >
> > Has anyone written such an escalation and the associated SCRIPT that
> would
> > have to be written to the UNIX side of the process call?
> >
> >
> >
> > You help, as always, would be greatly appreciated!
> >
> > Thanks,
> > Gp
> >
> > George Payne
> >
> > Corporate Applications Developer
> > Electric Reliability Council of Texas
> > (512) 248-3940
> > [EMAIL PROTECTED]
>
>
_______________________________________________________________________
> ________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
