151–160 of 179 posts
Earlier quoted context omitted.
QE? Is that a misspelling of QA, or is there another meaning beyond Quantitative Easing?
Quality engineering. It's Red Hat's term, as well as a few other software companies, but its QA.
Earlier quoted context omitted.
I have no direct information about this specific case, but in ye olden Unix™ days, there was no /sbin, so all those binaries instead lived in /etc. The Red Hat symlinks could be a backwards-compatibility thing.
You mean bug-compability?
Earlier quoted context omitted.
1. open bash 2. set -e 3. type an invalid command or run one that returns non-zero 4. "crap, where did my shell go?"
It could be the default for non-interactive shells without causing this problem. Or we could have a more nuanced rule, where -e means "stop executing the current sequence of commands as soon as there is an error", where a "sequence of commands" is a single line in an interactive shell (so "false; whoami" would print nothing), or the entire file in a script. The real answer is that this has not been the default in the…
Earlier quoted context omitted.
I would bet on the issue being in the init script itself rather than squid. (I'm assuming squid doesn't run as root by default in rhel) If that's true then it's another point for more sane process managers (upstart/supervisord/systemd/...)
"systemd" and "sane" only ever go in the same sentence as "sane people don't use systemd". It looks like a bug in the init script; runnign it as squid's user wouldn't have triggered destroying the whole filesystem; likely just squid's config and anything under its /var.
Earlier quoted context omitted.
I feel like it would be a frighteningly common bug. I remember one like this from 2011 [1]. Install/packaging/utility scripts usually do not get as much attention and testing as the application code itself. [1] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...
I'd say the fact that these bugs only very occasionally happen - relative to the huge number of shell scripts out there that are being executed every day - that it's not really "frighteningly common". You only hear about the ones that fail.
My good old trick to mitigate that is: touch /-@ I also always do it in my home directory: touch ~/-@ That's the first thing I do on a new host. When accidentally running rm -f *, the command expands to -@ first, which is not a valid option and makes the command fail before doing any harm rm: illegal option -- @ usage: rm [-f | -i] [-dPRrvW] file ...
That way the pain of having to type AsteRISKdeleteALL instead of * for rm events offsets any anxiety by far.
You can also catch the rm and mv to a difectory with quota's you can call a recycle bin, some low end attached storage can be fine as well as not many situations when your wildcard deleting with a time factor. Can accommodate this in your own skulker to clean up in a more organised way overall in a timely manner. and and scripts you can path to the real rm command if needs be, last time I called it P45Generator, but not the finest for readability in any such scripts.
"Thanks Swapna and Red Hat QE for catching this issue before the package was released. Great work!" Looks like this wasn't released into production.
For more details on why this issue doesn't affect squid users: https://rwmj.wordpress.com/2015/03/24/restarting-squid-resul...
Earlier quoted context omitted.
As someone who uses the commandline a lot but isn't exactly a wizard, why does this work?
The * is expanded by the shell to a space-delimited list of filenames, but the shell does not adequately escape filenames that can be misinterpreted as arguments to 'rm'.
That sounds like a bug to me, or at least depending on suboptimal behavior.
Earlier quoted context omitted.
I would bet on the issue being in the init script itself rather than squid. (I'm assuming squid doesn't run as root by default in rhel) If that's true then it's another point for more sane process managers (upstart/supervisord/systemd/...)
"systemd" and "sane" only ever go in the same sentence as "sane people don't use systemd". It looks like a bug in the init script; runnign it as squid's user wouldn't have triggered destroying the whole filesystem; likely just squid's config and anything under its /var.
Which is what happens when you have every daemon writing their own PID handling code, running as root, in a language whose interpolation rules nobody really understands.