21–30 of 179 posts
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…
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/...)
Agreed, I should've elaborated. All it takes is something like this in the init script without checking if the variable is empty: rm -rf "$STEAMROOT/"*
[1] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...
It looks like the start-up/shutdown script is doing an rm -rf on a bash variable that's evaluating to null.
It very well could have been an instance of the bumblebee bug (https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...) where it's "rm -f / some/file" instead of "rm -f /some/file"
Link to the code if you want to make that claim.
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/...)
Agreed, I should've elaborated. All it takes is something like this in the init script without checking if the variable is empty: rm -rf "$STEAMROOT/"*
It looks like the start-up/shutdown script is doing an rm -rf on a bash variable that's evaluating to null.
It's hard to trust anyone that would ever depend on such a variable without having some sort of precondition.
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.
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…
Earlier quoted context omitted.
Agreed, I should've elaborated. All it takes is something like this in the init script without checking if the variable is empty: rm -rf "$STEAMROOT/"*
That's not completely true. At least with the GNU tools, 'rm' won't delete the root directory unless you specifically give it the '--no-preserve-root' flag. Since that flag has no use outside of deleting root, it's unlikely it has the flag on it. With that in mind the script must do some type of manual deleting for some reason.
Earlier quoted context omitted.
Agreed, I should've elaborated. All it takes is something like this in the init script without checking if the variable is empty: rm -rf "$STEAMROOT/"*
That's not completely true. At least with the GNU tools, 'rm' won't delete the root directory unless you specifically give it the '--no-preserve-root' flag. Since that flag has no use outside of deleting root, it's unlikely it has the flag on it. With that in mind the script must do some type of manual deleting for some reason.
I love how deadpan the bug report is: Actual results: All files are deleted on the machine. Expected results: Squid is restarted. Not many details yet but it sounds similar to the Steam bug [0] from last year. [0] https://github.com/valvesoftware/steam-for-linux/issues/3671
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/...)
There were some circumstances where if there was no cache_dir line configured, or if the cache_dir was a link or something, the details are very sketchy in my mind after so much time, but it would end up destroying /.
I'm guessing this is of that same nature.
Earlier quoted context omitted.
> Does it really matter if no one commented "Oops, we screwed up"? To me it does. You just deleted someone's hard drive, an apology wouldn't be out of order.
When you're a QA engineer at RHEL working on an UNRELEASED PRODUCT then no, I don't think you need an apology. Maybe a thanks for finding the bug, but this is the whole point of QA and the whole point of QA-ing before it's released. The context matters a lot. This title is linkbait. It omits mentioning that this was not publicly released and the reporter is a QA for Red Hat. Given that context I doubt you'll still ag…