I’ve tested the command and it worked flawlessly in the terminal, but I have no idea what I’m doing, since I’m new to rust and never worked with this library
I’m guessing if input was “”, then it would sigkill all processes? Less confident, but some functions behave slightly differently in an interactive console vs a non interactive, maybe ps has a different format when used non interactively?
Aside, you want three backticks and a newline to get code formatting :)
I forgot to trimm the string, so it had a line break in it which lead to grep showing the processes from the term I put in + all processes that contain a space/linebreak and appearently all processes shown by ps aux contain some kind of space (makes sense, since there are spaces between the user, pid, etc) so yeah, I ended up trying to kill every process on the system, but it only killed the user processes, since I ran everything without sudo
Go to settings ->3D configuration -> projection -> projection type->. Cycle through the projection types. One of them causes something good enough to call a crash.
I don’t remember anymore if it was just a display driver crash or a kernel crash and I haven’t updated to a newer version (which might have fixed it).
It needs to startup and then go to that point (after you select the projection) to cause the crash.
It definitely caused something other than the application to get into an invalid state. Which is why I am apprehensive about trying it out again to answer your comment. Probably was the display driver, which is why it didn’t just turn off after that.
That won’t crash your kernel, and I was more curious about the OPs example. Task management is basically reading some files, and sending signals, it should be near impossible to crash the system.
Kernel shouldn’t crash, and anything running in memory will be okayish, but it definitely will get less and less stable. It won’t be possible to start new processes.
I have a Linux install on a USB SSD with a flakey connection, if I bumped the cord the root would unmount. It was fairly resilient, but graphics would slowly start disappearing. I’m fairly sure I could cleanly reboot as long as I had a terminal open, but its been a while, so maybe I’m misremembering.
Still, the overall system becomes pretty useless, so i guess its fair to call it a crash
How are you crashing your system?! Crashing program sure, but the entire system?
Try it out on your own system.
It’s totally possible
Doesn’t explain OPs task management example. And won’t crash the kernel, just make things unresponsive
it didn’t crash the kernel, it just killed every process that isn’t run by the root user, which kind of feels like a crash
Ah, that definitely would feel like a crash. Sent kill signal to cgroup accidentally? Or just iterate over all processes and signal them all?
probably the later, but idk how, all I did was insert a string in the following command like this:
`Command::new(“bash”)
.arg(“-c”) .arg(format!(“ps -aux | grep -i "}" }’ | xagrs kill -9”, input)
.output()
.expect(“error”);`
I’ve tested the command and it worked flawlessly in the terminal, but I have no idea what I’m doing, since I’m new to rust and never worked with this library
There are rust libraries to send signals, might be better to use those rather than calling bash. eg. https://docs.rs/nix/latest/nix/sys/signal/index.html
I’m guessing if input was “”, then it would sigkill all processes? Less confident, but some functions behave slightly differently in an interactive console vs a non interactive, maybe
pshas a different format when used non interactively?thx, btw I figured it out:
I forgot to trimm the string, so it had a line break in it which lead to grep showing the processes from the term I put in + all processes that contain a space/linebreak and appearently all processes shown by ps aux contain some kind of space (makes sense, since there are spaces between the user, pid, etc) so yeah, I ended up trying to kill every process on the system, but it only killed the user processes, since I ran everything without sudo
deleted by creator
There’s this game “HyperRougue”. Run it on Arch.
hyperrogue-git version 13.0d.r60.g27fb2d92-1Go to
settings -> 3D configuration -> projection -> projection type ->. Cycle through the projection types. One of them causes something good enough to call a crash.I don’t remember anymore if it was just a display driver crash or a kernel crash and I haven’t updated to a newer version (which might have fixed it).
Doesn’t even startup on my box, but doesn’t crash the kernel or system either, just regular application crash
It needs to startup and then go to that point (after you select the projection) to cause the crash.
It definitely caused something other than the application to get into an invalid state. Which is why I am apprehensive about trying it out again to answer your comment. Probably was the display driver, which is why it didn’t just turn off after that.
Works for
.current directory. Yay!… also works for
/system root. 🔥 Nay!Does it? I thought / specifically was protected, and you needed to add --no-preserve-root.
It should, but I the end it depends on your system. Each distro has their own default behavior.
That won’t crash your kernel, and I was more curious about the OPs example. Task management is basically reading some files, and sending signals, it should be near impossible to crash the system.
I believe it does crash the system eventually as important buts start to go missing?
Kernel shouldn’t crash, and anything running in memory will be okayish, but it definitely will get less and less stable. It won’t be possible to start new processes.
I have a Linux install on a USB SSD with a flakey connection, if I bumped the cord the root would unmount. It was fairly resilient, but graphics would slowly start disappearing. I’m fairly sure I could cleanly reboot as long as I had a terminal open, but its been a while, so maybe I’m misremembering.
Still, the overall system becomes pretty useless, so i guess its fair to call it a crash
A high level explanation
OPs example was task management, which doesn’t require kernel modules.