Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug 1202858 – Restarting squid results in deleting all files in hard-drive

bugzilla.redhat.com

Post reply on HN
Print view View original

101–110 of 179 posts

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#101

Post by stbenjam »

vacri wrote: post #30
TheDong wrote: post #19

Earlier quoted context omitted.

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…

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...

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#102

Post by ownagefool »

lmm wrote: post #95
cellularmitosis wrote: post #40

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?

To be fair to Debian, that's how it's supposed to work. You untar into /opt, self contained, while your apt install puts things in the Filesystem Hierarchy Standard, which means config goes into /etc.

You'll find most distros follow some FHS standard, although there's some differences in interpretation.

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#103

Post by atmosx »

jedisct1 wrote: post #47

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 ...

Hm that's a cool trick. IIRC some distributions (Suse?) had a 'bash' clause where you couldn't do "rm -rf /" without 'y'.

My 'zsh' has this one too, when I 'rm -rf /some/dir/' always asks if I'm "sure". Truth to be told, I'm not even expecting the text in "stdout" anymore, my finger goes to the 'y' automatically, which means that if I make something stupid it won't be able to protect me :-P

The last couple of years I stopped doing 'stupid things' by stop working on the shell when I'm very tired. That was the cause of my rm-related-incidents in the past :-)

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#104

Post by blueskin_ »

viraptor wrote: post #7
kevan wrote: post #3

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/...)

"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.

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#105

Post by Aissen »

jedisct1 wrote: post #47

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 ...

rm -rf -- $EMPTY_VAR/*

Ooops.

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#106

Post by blueskin_ »

guardian5x wrote: post #74
lpsz wrote: post #32

Earlier quoted context omitted.

And this is why it is important to write something like set -eu on top of your bash scripts -- execution will stop on errors (non-zero retvals) and on undefined variables.

I wonder why set -eu is not the default setting.

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?"

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#107

Post by jakobegger »

VieElm wrote: post #41
elchief wrote: post #4

We had one of these kinda bugs. If you uninstalled our software it deleted a major chunk of your Windows registry, crippling your computer. It was a one character error in our script. The first ticket read "Uninstalling [Product] destroys your computer". I was responsible for customer support. Good times! Was a rough week. We managed to not get sued.

Pretty terrible that such a thing is even allowed by Windows. This is why as a user I like Apple's OS X sandbox.

About a year ago or so I tried to fix a computer of an OS X user where the Dropbox installer somehow deleted the home directory and replaced it with the dropbox application... That was an odd experience (and one where sandbox didn't help...)

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#108

Post by nwalfield »

cellularmitosis wrote: post #38
lpsz wrote: post #32

Earlier quoted context omitted.

And this is why it is important to write something like set -eu on top of your bash scripts -- execution will stop on errors (non-zero retvals) and on undefined variables.

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

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#109

Post by rwmj »

mplewis wrote: post #15

I'm having trouble finding the related commit that fixed this, can anyone else find it?

This bug is an internal QA bug. The reporter is a Red Hat tester. The buggy RPM was never released outside Red Hat, and so there's no requirement to release the source. When RHEL 6.7 comes out the source will go up on ftp.redhat.com.

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#110

Post by cssmoo »

rwmj wrote: post #85
cssmoo wrote: post #69

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.

This is simply not true. Could you provide evidence rather than making stuff up.

Ok.

Fresh steaming proof as requested:

https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&...

All high severity bugs against 7.1 which was relased 16 days ago. Check the dates on half of them. They're before the release date and half of them haven't even been assigned or triaged.

When 7.0 came out, datetimectl and systemd didn't even work properly. Enabling ntp threw dbus errors galore. On some kit it didn't even boot. Total lemon.

RHEL doesn't generally work properly until the .2 releases. I've been using it for 10 years so I've got plenty of experience on the matter.

I would go into detail about the CIFS/smb kernel hangs I've had on 6.x but I've had enough of it by now.

Post reply on HN