7 ms·

Also, as a safety net, sometimes you don't need to run `rm -rf` (a command which should always be prefaced with 5 minutes of contemplation on a production syste

by theptip 10y ago

Also, as a safety net, sometimes you don't need to run `rm -rf` (a command which should always be prefaced with 5 minutes of contemplation on a production system). In this case, `rmdir` would have been much safer, as it errors on non-empty directories.

bpchaps 10y ago
These days, I've been very implicit in how I run rm. To the extent that I don't do rm -rf or rmdir (edit: immediately), but in separate lines as something like: pushd dir ; find . -type f -ls | less ; find . -type f -exec rm '{}' \; ; popd ; rm -rf dir It takes a lot longer to do, but I've seen and made enough mistakes over the years that the forced extra time spent feels necessary. It's worked pretty well so far -- knock knock.
- gizmo 10y ago
  Good advice. I would add a step where you dump the output of find (after filtering) into a textfile, so you have a record of exactly what you deleted. Especially when deleting files recursively based on a regular expression that extra step is very worthwhile. It's also a good practice to rename instead of delete whenever possible. Rename first, and the next day when you're fresh walk through the list of files you've renamed and only then nuke them for good.
- kstrauser 10y ago
  BTW, find ... -delete avoids any potential shell escaping weirdness and saves you a fork() per file.
  - wodny 10y ago
    This seems to be the best here. As a side note: if someone does something more complicated and uses piping find output to xargs, there are very important arguments to find and xargs to delimit names with binary zero -- -print0 and -0 respectively. Very interesting article: https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html https://www.dwheeler.com/essays/fixing-unix-linux-filenames.....
    - willemmali 10y ago
      I've been writing an `sh`-based tool to check up on my local Git repos, and it uses \0-delimited paths and a lot of `find -print0` + `xargs -0`: https://gitlab.com/willemmali-sh/chegit/blob/master/chegit#L703 https://gitlab.com/willemmali-sh/chegit/blob/master/chegit#L... I admit the code can look a little weird, but it was because I had some rather tight contrainst: 1 file, all filenames `\0` separated internally and just POSIX `sh`. I still wanted to reuse code and properly quote variables inside `xargs` invocations (because `sh` does not support `\0`-separated read's), so I ended up having to basically paste function definitions into strings and use some fairly expansive quotation sequences.
      - bpchaps 10y ago
        Nice plug for gitlab ;). \0 is an insanely useful separator for this sort of thing and yeah, it definitely gets messy. I'm working on a similar project that uses clojure/chef to read proc files in a way that causes as little overhead as possible. \0 makes life so much easier used. The best example I can think of off of the top of my head is something similar to: bash -c "export FOO=1 ; export BAR=2 && cat /proc/self/environ | tr '\0' '\n' | egrep 'FOO|BAR'" FOO=1 BAR=2
        willemmali 10y ago
        I was so freaked out at the news, I normally have local backups of my projects but I just happened to be in the middle of a migration where my code was just on Gitlab, and then they went down... Luckily it all turned out OK. \0 is very useful but I really wish for an updated POSIX sh standard with first-class \0 support. On your code, why do you replace \0's with newlines? egrep has the -z flag which makes it accept \0-separated input. A potential downside to it is that it automatically also enables the -Z flag (output with \0 separator). I solved the "caller might use messy newline-separated data"-problem by having an off-by-default flag that makes all input and output \0-separated; this is handled with a function called 'arguments_or_stdin' (which does conversion to the internal \0-separated streams) and 'output_list' (which outputs a list either \0- or \n-separated depending on the flag).
- deleted 10y ago
  [deleted]
piinbinary 10y ago
Or use `mv x x.bak` when `rmdir` fails
- shawn-furyan 10y ago
  Or even instead of any kind of rm command. mv is less subtle. I tend to prefer `mv x $(date +%Y%m%d_%s_)x` where: %Y - 4 digit year %m - 2 digit month %d - 2 digit day _ - underscore literal %s - linux timestamp (seconds since epoch) This ensures that the versions you're 'removing' will be lexically sorted from newest to oldest in a way that is easy to interpret and also works if you need to try more than once in a day. In case it's not apparent to some, this command moves the directory (or file) called 'x' to something like '20170131_1485916040_x' Then when you're all done (i.e. production is humming and passing tests, no need to ever rush), you can delete the timestamped version, or if space is plentiful, move the old file to an archive directory as an extra redundancy (i.e. as an extra backup, not in lieu of a more thorough backup policy).
  - krenoten 10y ago
    This needs to be the first thing anyone who works with stateful systems learns. NEVER rm. mv is insufficient. mv dir dir.bak.`date +%s` has prevented data loss for me several times.
    - deleted 10y ago
      [deleted]
    - bpchaps 10y ago
      I agree with what you're saying, and this is almost exactly what I do, but when disk space is limited - particularly during time-sensitive situations - this advice isn't very useful. For example, if a host or service is on the cusp of crashing because of a partition quickly filling up with rolling logs, what do you do since mv doesn't actually solve the problem? At some level you have to run an rm, and you better hope you do it right in the middle of an emergency with people breathing over your shoulder. In an ideal world, this wouldn't ever happen, but it does. Inherited/legacy systems suck.
foobiekr 10y ago
I am actually curious what user they were logged in as and what permissions were in effect. Unfortunately, the answer most places is that the diagnostic account (as opposed to the corrective action account) is fully privileged (or worse, root).
- YorickPeterse 10y ago
  A regular user that can use `sudo`.
- kelnos 10y ago
  From a comment in the doc ("YP says it’s best for him not to run anything with sudo any more today, handing off the restoring to JN"), I assume they're running as a regular user, sudo'ing as necessary.
weavie 10y ago
Alternatively, if you have the luxury - `zfs snapshot`.
- chousuke 10y ago
  Having a snapshotting storage system (NetApp) once saved a lot of pain when I accidentally deleted the wrong virtual machine disk from an internal server (hit the system disk instead of a removed data disk) I was able to recover the root disk from a snapshot and bring up the machine in less than an hour. Snapshots are not a backup strategy, but they make me sleep better at night regardless.
Bad_CRC 10y ago
lsof -> check if a process is accessing that file/directory.

by theptip 10y ago

bpchaps 10y ago

These days, I've been very implicit in how I run rm. To the extent that I don't do rm -rf or rmdir (edit: immediately), but in separate lines as something like: pushd dir ; find . -type f -ls | less ; find . -type f -exec rm '{}' \; ; popd ; rm -rf dir It takes a lot longer to do, but I've seen and made enough mistakes over the years that the forced extra time spent feels necessary. It's worked pretty well so far -- knock knock.

gizmo 10y ago
Good advice. I would add a step where you dump the output of find (after filtering) into a textfile, so you have a record of exactly what you deleted. Especially when deleting files recursively based on a regular expression that extra step is very worthwhile. It's also a good practice to rename instead of delete whenever possible. Rename first, and the next day when you're fresh walk through the list of files you've renamed and only then nuke them for good.
kstrauser 10y ago
BTW, find ... -delete avoids any potential shell escaping weirdness and saves you a fork() per file.
- wodny 10y ago
  This seems to be the best here. As a side note: if someone does something more complicated and uses piping find output to xargs, there are very important arguments to find and xargs to delimit names with binary zero -- -print0 and -0 respectively. Very interesting article: https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html https://www.dwheeler.com/essays/fixing-unix-linux-filenames.....
  - willemmali 10y ago
    I've been writing an `sh`-based tool to check up on my local Git repos, and it uses \0-delimited paths and a lot of `find -print0` + `xargs -0`: https://gitlab.com/willemmali-sh/chegit/blob/master/chegit#L703 https://gitlab.com/willemmali-sh/chegit/blob/master/chegit#L... I admit the code can look a little weird, but it was because I had some rather tight contrainst: 1 file, all filenames `\0` separated internally and just POSIX `sh`. I still wanted to reuse code and properly quote variables inside `xargs` invocations (because `sh` does not support `\0`-separated read's), so I ended up having to basically paste function definitions into strings and use some fairly expansive quotation sequences.
    - bpchaps 10y ago
      Nice plug for gitlab ;). \0 is an insanely useful separator for this sort of thing and yeah, it definitely gets messy. I'm working on a similar project that uses clojure/chef to read proc files in a way that causes as little overhead as possible. \0 makes life so much easier used. The best example I can think of off of the top of my head is something similar to: bash -c "export FOO=1 ; export BAR=2 && cat /proc/self/environ | tr '\0' '\n' | egrep 'FOO|BAR'" FOO=1 BAR=2
      - willemmali 10y ago
        I was so freaked out at the news, I normally have local backups of my projects but I just happened to be in the middle of a migration where my code was just on Gitlab, and then they went down... Luckily it all turned out OK. \0 is very useful but I really wish for an updated POSIX sh standard with first-class \0 support. On your code, why do you replace \0's with newlines? egrep has the -z flag which makes it accept \0-separated input. A potential downside to it is that it automatically also enables the -Z flag (output with \0 separator). I solved the "caller might use messy newline-separated data"-problem by having an off-by-default flag that makes all input and output \0-separated; this is handled with a function called 'arguments_or_stdin' (which does conversion to the internal \0-separated streams) and 'output_list' (which outputs a list either \0- or \n-separated depending on the flag).
deleted 10y ago
[deleted]

piinbinary 10y ago

Or use `mv x x.bak` when `rmdir` fails

shawn-furyan 10y ago
Or even instead of any kind of rm command. mv is less subtle. I tend to prefer `mv x $(date +%Y%m%d_%s_)x` where: %Y - 4 digit year %m - 2 digit month %d - 2 digit day _ - underscore literal %s - linux timestamp (seconds since epoch) This ensures that the versions you're 'removing' will be lexically sorted from newest to oldest in a way that is easy to interpret and also works if you need to try more than once in a day. In case it's not apparent to some, this command moves the directory (or file) called 'x' to something like '20170131_1485916040_x' Then when you're all done (i.e. production is humming and passing tests, no need to ever rush), you can delete the timestamped version, or if space is plentiful, move the old file to an archive directory as an extra redundancy (i.e. as an extra backup, not in lieu of a more thorough backup policy).
- krenoten 10y ago
  This needs to be the first thing anyone who works with stateful systems learns. NEVER rm. mv is insufficient. mv dir dir.bak.`date +%s` has prevented data loss for me several times.
  - deleted 10y ago
    [deleted]
  - bpchaps 10y ago
    I agree with what you're saying, and this is almost exactly what I do, but when disk space is limited - particularly during time-sensitive situations - this advice isn't very useful. For example, if a host or service is on the cusp of crashing because of a partition quickly filling up with rolling logs, what do you do since mv doesn't actually solve the problem? At some level you have to run an rm, and you better hope you do it right in the middle of an emergency with people breathing over your shoulder. In an ideal world, this wouldn't ever happen, but it does. Inherited/legacy systems suck.

foobiekr 10y ago

I am actually curious what user they were logged in as and what permissions were in effect. Unfortunately, the answer most places is that the diagnostic account (as opposed to the corrective action account) is fully privileged (or worse, root).

YorickPeterse 10y ago
A regular user that can use `sudo`.
kelnos 10y ago
From a comment in the doc ("YP says it’s best for him not to run anything with sudo any more today, handing off the restoring to JN"), I assume they're running as a regular user, sudo'ing as necessary.

weavie 10y ago

Alternatively, if you have the luxury - `zfs snapshot`.

chousuke 10y ago
Having a snapshotting storage system (NetApp) once saved a lot of pain when I accidentally deleted the wrong virtual machine disk from an internal server (hit the system disk instead of a removed data disk) I was able to recover the root disk from a snapshot and bring up the machine in less than an hour. Snapshots are not a backup strategy, but they make me sleep better at night regardless.

Bad_CRC 10y ago

lsof -> check if a process is accessing that file/directory.