Running the yes command in command substitution will crash the linux shell. According to me inside command the substitution it is creating multiple process(fork). Command: `yes`
(In reply to lithack from comment #0) > Running the yes command in command substitution will crash the linux shell. > According to me inside command the substitution it is creating multiple > process(fork). > > Command: `yes` Seems like coreutils issue (try posting to its appropriate list instead [1]). Please don't use Kernel Bugzilla for pure userspace issues like this. [1]: https://lists.gnu.org/archive/html/coreutils/
What's your Linux distribution and version? What's your device and its RAM/CPU? What's the exact steps to reproduce the issue? How do you it's the kernel that crashed? Do you have a kernel panic/oops? What's the kernel version?
(In reply to Bagas Sanjaya from comment #1) > > Seems like coreutils issue (try posting to its appropriate list instead [1]). > > Please don't use Kernel Bugzilla for pure userspace issues like this. > > [1]: https://lists.gnu.org/archive/html/coreutils/ It's _not_ necessary to reply to all the bug reports here, specially if you don't have the knowledge of what's going on. This is not a public forum, this is a kernel bug tracker.
Created attachment 304440 [details] Screenshot from 2023-06-17 22-02-41.png To recreate it just type the command {`yes` or $(yes)} basically running the command "yes" inside the command substitution. Here is all necessary information what you asked for. Thanks and regards. On Sat, 17 Jun 2023 at 21:41, <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=217565 > > Artem S. Tashkinov (aros@gmx.com) changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|NEW |NEEDINFO > > --- Comment #2 from Artem S. Tashkinov (aros@gmx.com) --- > What's your Linux distribution and version? > > What's your device and its RAM/CPU? > > What's the exact steps to reproduce the issue? > > How do you it's the kernel that crashed? Do you have a kernel panic/oops? > What's the kernel version? > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You reported the bug.
Created attachment 304441 [details] Screenshot from 2023-06-17 22-01-13.png
Looks like you ran a fork bomb and it worked. Please try enabling nproc limits in /etc/security/limits.conf This is not a kernel bug, this a distribution bug. Here's the proper bug tracker: https://bugs.launchpad.net/ubuntu
https://www.google.com/search?q=linux+fork+bomb Has all the info. The kernel does not crash in your case, your system just becomes totally unresponsive since you're running hundreds of thousands of processes.
Created attachment 304450 [details] attachment-23576-0.html Ok thanks for the clarification. On Mon, Jun 19, 2023, 1:47 AM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=217565 > > Artem S. Tashkinov (aros@gmx.com) changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|NEEDINFO |REJECTED > Resolution|--- |DOCUMENTED > > --- Comment #6 from Artem S. Tashkinov (aros@gmx.com) --- > Looks like you ran a fork bomb and it worked. > > Please try enabling nproc limits in /etc/security/limits.conf > > This is not a kernel bug, this a distribution bug. > > Here's the proper bug tracker: https://bugs.launchpad.net/ubuntu > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You reported the bug.
Created attachment 304451 [details] attachment-31336-0.html I have tested this in many linux based kernel distribution and found same behaviour so I think there is problem in kernel because the way it treats the signal is fishy. On Mon, Jun 19, 2023, 1:48 AM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=217565 > > --- Comment #7 from Artem S. Tashkinov (aros@gmx.com) --- > https://www.google.com/search?q=linux+fork+bomb > > Has all the info. > > The kernel does not crash in your case, your system just becomes totally > unresponsive since you're running hundreds of thousands of processes. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You reported the bug.
> I think there is problem in kernel because the way it treats the signal is fishy Configure maximum nproc limits in /etc/security/limits.conf and be happy.
I'm not even sure what "signal" and "fishy" you are talking about. This is a well defined piece of software which mostly has a deterministic behavior. The word "fishy" doesn't apply to it. Signals exist, `man kill` and kill -l are for that, but that's definitely not what you had in mind. Please ask your question on some Unix/Linux forum, e.g. https://unix.stackexchange.com/questions , this a kernel bugzilla.