111–120 of 179 posts
Earlier quoted context omitted.
RH don't have a great reputation here. Unlike Debian which does proper triage and practices "zero release-critical bugs", RH threw out RHEL7 with loads of critical issues still open.
Ah yes, like good old DSA-1571-1
Earlier quoted context omitted.
Oh, I see.
Specifically, this bug would not have happened with systemd since systemd does not leave the handling of pid-files and pid-dirs to shell-scripts.
Every time I've seen such a bug (honestly, not many), it was created when cleaning a temporary dir.
Earlier quoted context omitted.
This being said, the bugtracker isn't very clear when it comes to ticket status. Currently the status is 'on_qa'. I guess if you use it a lot you're aware of it, but it strikes me as iffy UI.
It's exceptionally clear for anyone even remotely familiar with RHEL or Bugzilla. It's not mean for any joe's consumption anyway, this is a work tool used by developers and QE...
this is a work tool used by developers and QE
Because as we all know, developers don't benefit from good UIs. One wonders why they would use a webpage at all, rather than simply connect to an ncurses-based bugtracker that only supports an 80x24 terminal.
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.
"it's hard to trust anyone that writes a dumb bug". Listen to yourself. We've all written dumb bugs. We've all had that one line of code that was an obvious mistake. I still trust people who write a bug here and there because if I didn't I would have to forgo trusting everyone for everyone makes dumb mistakes sometimes.
At this point I refuse to trust anyone who writes shell scripts. Bugs happen, but a shell script is practically guaranteed to have zero automated tests and variable-related bugs are all too common.
Thanks OP, this actually made me laugh uproariously. Anyway, I'd be willing to bet 100 push-ups that (unless it was malicious and not a bug), this thing is caused by some clean up code somewhere that originally intended to do "rm -rf /path/to/squid/socket" but the function that was suppose to generate the "/path/to/squid/socket" string instead generated a null which was then parseString'd onto a "" via some + functio…
That's almost exactly how I blew up a test server once. (rsync --delete in place of rm) Taught me to be extremely careful when dealing with absolute directory paths.
Earlier quoted context omitted.
or check the variable before using it, like any other programming language: [[ "$VAR" ]] && rm -rf "$VAR/*" I think most of these issues stem from the fact that most developers that write shell scripts don't actually understand what they're doing, treating the script as a necessary annoyance rather than a component of the software.
If anyone understands shell scripts, it would be people writing init scripts at Red Hat :) Anyways, that is not anything like other programming languages. Checking in that way is error prone and not really an improvement (nor equivalent to set -o). [[ "$DAEMON_PATH" ]] && rm -rf "$DEAMON_PATH/*" See what I did there? It's an rm -rf /* bug because "checking variables" is not the answer. In other programming languages,…
Earlier quoted context omitted.
Ahh Redhat, the distro which chose to symlink a bunch of binary lib files from Apache into the etc directory. "Why is grepping /etc taking so long? Binary files in /etc?!? WTF?!?" Coming from Debian, Redhat seems to make a lot of irk-worthy choices.
As opposed to Debian, the distro which chooses to break tomcat (a program which unzips into a single folder and is thereby completely self-contained) up into a million different pieces and scatter them randomly all over your hard drive?
(That said, making the package self contained is the most sensible way for the developer to release it. It's just not a good option for a distro package.)
Earlier quoted context omitted.
I also include set -o pipefail (exit if ANY command in a pipeline fails). Had to get bitten and waste an hour before that became a habit. set -e and set -o pipefail really should have been the default, rather than an opt-in.
set -o pipefail makes common idioms a pain. Consider using head, which simply exits after it has read a few lines. In this case, the input process gets a SIGPIPE and exits with a non-zero exit code: Consider /tmp/test.sh: set -o pipefail yes foo | head $ bash /tmp/test.sh >/dev/null $ echo $? 141
I've collated other mishandling of closed pipes at: http://www.pixelbeat.org/programming/sigpipe_handling.html
"Thanks Swapna and Red Hat QE for catching this issue before the package was released. Great work!"