[Xymon] Testing Terabithia packages updated to 4.3.29-0.6

Japheth Cleaver cleaver at terabithia.org
Mon May 6 22:54:52 CEST 2019


On 5/6/2019 12:01 PM, Matt Vander Werf wrote:
> I would think it would be good if it wasn't required for the clients, 
> IMO. At least for us, EPEL is not on all our client systems (nor do we 
> expect it ever will be). I imagine this isn't unusual a case either. 
> bash is almost always universally available, so it makes more sense to 
> me to stick with that for clients.
>
> I completely expect that the server may need EPEL installed for it to 
> get everything it needs.
>
> Out of curiosity, what is the reason for using dash over bash? I don't 
> have much familiarity with dash, so I wasn't sure.

A combination of performance, security, and a bit of cargo cultism from 
back in the earliest days of the packages. dash (and its predecessor 
ash) are tiny compared to bash, so they launch much quicker and are less 
likely to have side-effects from a bash profile change accidentally 
affecting the xymon user account. The latter (ash) was actually often 
compiled statically as well, which made it even more resilient to some 
sort of library/package update mishap.

On resource-constrained systems, forking overhead can add up -- 
especially if it happens in a critical loop somewhere. One of xymon's 
strengths is that there's actually very little forking that occurs once 
the server has started up, but alarm scripts during a flood, or a lot of 
hits to the shell scripts that launch(ed) for each CGI (svcstatus.sh, 
etc) can tip over a box.

On the Debian/Ubuntu side, a lot of the rationale given behind 
https://wiki.ubuntu.com/DashAsBinSh is still basically valid. Fedora/EL 
probably would have pushed something like this *eventually*, but it was 
around this time that systemd was proposed as the end-all solution to 
long boot times. The rest, as they say, is history.

HTH,

-jc




More information about the Xymon mailing list