Skip Navigational Links
LISTSERV email list manager
LISTSERV - COMMUNITY.EMAILOGY.COM
LISTSERV Menu
Log In
Log In
LISTSERV 17.5 Help - LSTSRV-L Archives
LISTSERV Archives
LISTSERV Archives
Search Archives
Search Archives
Register
Register
Log In
Log In

LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Menu
LISTSERV Archives LISTSERV Archives
LSTSRV-L Home LSTSRV-L Home

Log In Log In
Register Register

Subscribe or Unsubscribe Subscribe or Unsubscribe

Search Archives Search Archives
Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
Re: Monitoring listserv on AIX
From:
Valdis Kletnieks <[log in to unmask]>
Reply To:
LISTSERV give-and-take forum <[log in to unmask]>
Date:
Sun, 5 Dec 1999 21:54:45 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
On Sat, 04 Dec 1999 09:07:14 EST, Bill Verity <[log in to unmask]>  said:
> What tools or techniques to you use to monitor listserv's status on AIX?
>
> On VM, we watched the reader file queue.  If it got large, someone was called.
> This was automated so it worked without depending on frail humans :-)
>
> We are just now moving to the AIX platform.  I came in this morning
> and found the server had stopped running at 00:30.  There were no
> errors in the log.  It just stopped.  Have to catch this earlier
> somehow.

A good trick under AIX is to get /etc/init to (a) launch listserv
at system IPL time and (b) restart it if it terminates. We have this
in /etc/inittab:

listserv:2:respawn:/home/listserv/go bg

which re-launches it if it exits (due to 'respawn').  The
way we roll the logs every night is with a 'cron' job that
just does a 'kill -TERM' of the lsv process, and a little bit
of magic in the 'go.user' code - since that's a shell script,
and it's being run when the server starts, we *know* it's a good
time to roll all the logs.

I second the comments about checking process limits - we had problems
with the lsv process going *poof* until we changed the 'Soft DATA segment'
limit to -1 (go to 'Change/Show Characteristics of a User' in SMIT).
This is particularly important if you've raised the values of the
FIOC_* variables in go.user.

Also, use 'lsps -a' and make sure you have enough paging space allocated.

/Valdis

ATOM RSS1 RSS2

COMMUNITY.EMAILOGY.COM CataList Email List Search Powered by LISTSERV