Re: running too much instances of perl in parallel
Kirk Bauer <[email protected]>
| Newsgroups | gmane.comp.log.logwatch.devel |
|---|---|
| Message-ID | <[email protected]> |
Agreed -- originally the idea was that it would be easy for people to write individual filters, potentially in languages other than Perl, that can stack up in a Unix-like fashion. We have certainly move somewhat away from that model to some degree, but at the core this is still how it works. LogWatch could certainly be rewritten to be much more efficient in many ways (this is just one of them) but I know I just don't have the time for it personally, but would support such an effort if somebody was interested in taking it on. ------------------------------------------------------ Kirk Bauer <[email protected]> http://linux.kaybee.org | www.logwatch.org Author, Automating UNIX & Linux Administration On Thu, Jun 11, 2009 at 7:13 AM, Mike Tremaine<[email protected]> wrote: > Ivana Varekova wrote: >> >> Mike Tremaine wrote: >>> >>> Ivana Varekova wrote: >>>> >>>> Hello, >>>> I just get a bug-report - which complains about the multiple instances >>>> of perl running at one time: >>>> >>>> "I noticed on F10 x86_64 machine that logwatch runs 10 perl instances >>>> and moves my AMD CPU temp to 90 C. >> >> Thanks, that will reduce the perl instances, if you prefer it I can do the >> patch. >> But what about use of procedures instead of scripts? >> Ivana > > Well it's certainly possible but it would be some major patching compared to > the 3 line fix. The bigger problem goes to the heart of the original > development of logwatch. Since logwatch is not thread aware and has lots of > inefficiencies we've always used the "Unix" idea of lots of small tools and > process forks to get the job done. Without a major rewrite I'm not sure we'd > get an improvement with a procedural approach. But keep in mind that I have > the disadvantage of too much time doing the same thing so if you see [or > anyone else sees] and a new direction feel free to code it out and explain > why it is better and so long as it doesn't break everything I'm sure it > would get included. > > -Mike > > _______________________________________________ > Logwatch-Devel mailing list > [email protected] > http://www2.list.logwatch.org:81/mailman/listinfo/logwatch-devel > >