FWIW, after I saw your problem report, I installed a very basic mon instance on a solaris 8 (108528-08) box in 64-bit mode, running perl 5.6.0, and did not see problems like what you described. Actually, it worked fine.
But as you mentioned it sounds like something with perl was to blame. It might help to see the output of the perl -V from the 'bad perl'. My perl was built with gcc 2.95.2. Also note that gcc can't build 64-bit sparc binaries, unless something has changed very recently, you need the SUNWpro (now Forte) compiler to do that. But running 32-bit apps in 64-bit solaris is not a problem, in every case I have ever seen. Glad you got the problem resolved. On Thursday 27 September 2001 02:13 pm, Nate Campi wrote: > On Wed, Sep 26, 2001 at 01:33:14PM -0700, Nate Campi wrote: > > Mon version is mon-0-99-1.8, on Solaris 8 (sparc). What happens is when > > I start Mon as a "mon" user, in /usr/local/mon (recursively owned by the > > "mon" user), it forks off as many instances of the mon command line as > > the systems will allow until memory is exhausted. > > I upgraded to perl 5.6.1 and the problems went away. I'd recommend > against perl 5.6.0 on Solaris 8/sparc. I use gcc, and I've heard of > problems with gcc on 64 bit sparc. The thing is - I have live > webservers on solaris 8, built with gcc and no problems. I build > everything with gcc. Go figure. > > Anyways, my boss I have talked all of Lycos into moving to Mon, away > from BB. See my recent posting to the BB mailing list regarding Mon: > http://support.bb4.com/archive/200109/msg00932.html > > Noone argued with me at all ;) One person did email me asking about what > Mon was, I sent a link to the web page. > > Our Mon is for internal use, not anything publicly viewable. We have a > lot of "properties" that have been aquired by Lycos over time, and > everyone runs BB, usually heavily customized. I had hacked the hell out > of BB to get it to do some of the things we need, but BB is a big shell > hack to begin with, and more hacks only made it uglier. > > We have a big project (not headed by me thank god) to move slowly over > to Mon. People really liked my production instance of Mon where it > monitors IIS servers, and takes them out of service in a load balancer > when they fail (alert scripts written in expect). It then uses another > alert script (expect scripts again) to restart IIS on the machine. At > the next UPALERT it puts the machine back in service in the load > balancer. If all this fails to fix the machine it uses a "period" > statement to page an admin to fix it manually. In an environment like > ours where large clusters of crappy IIS servers fail regularly, this > keeps uptime at maximum and lets admins sleep at night. > > We used to have a custom perl system to do this, but I ported it to Mon > for the superior scheduler and alerting capabilities. > > My Mon install does much more, but the flexibility to do the automated > restarts is a huge benefit, and a major reason we've moved to Mon.
