[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