| View previous topic :: View next topic |
| Author |
Message |
Gentoopc
Apprentice
Joined: 25 Dec 2017
Posts: 296
|
 Posted: Thu Sep 21, 2023 3:38 am Post subject: fork |
 |
|
| hello forum. who can say for sure what will happen to the kernel if fork() stops spawning processes? has anyone encountered this in reality? |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Thu Sep 21, 2023 5:04 am Post subject: |
|
|
What do you mean?
This would sort of break a lot of stuff of course. Shell scripts would stop running properly too.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1751
|
| Posted: Thu Sep 21, 2023 11:09 am Post subject: |
|
|
One thing I can think of users on systemd systems will be unable to log in.
This is based on my limited understanding that a systemd process is spawned for every user session. I might be completely wrong though.
Best Regards,
Georgi |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Thu Sep 21, 2023 4:52 pm Post subject: |
|
|
It's not just systemd that will fail, in fact there will probably be less problems with systemd because everything is already loaded and no need for forking additional shell scripts, helper programs, etc. to continue running -- but eventually, due to the nature of un*x in general, fork() will need to be run and things will break right there.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21918
|
| Posted: Thu Sep 21, 2023 6:18 pm Post subject: |
|
|
The kernel is unlikely to suffer any particularly bad problems if fork fails. It has error handling. However, as others have described, your user processes will not take well to it.
Could you explain why you are asking? |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3203
|
| Posted: Thu Sep 21, 2023 6:22 pm Post subject: |
|
|
What do you mean by "stop"? Not work at all?
The first thing that comes to my mind is flat out kernel panic instead of boot. PID 1, also known as init is a process.
Run 'ps auxwf', AFAIR all commands in [square brackets] run in kernel space. Some of them have quite high PIDs too, which means they were started long after boot.
Stop like stop after system is already running? You can test it by exhausting space in PID table with a fork bomb. For starters, your system will hang up.
Also, how do you want it to fail? It might affect the resulting behavior. Return an error code? Report success without actually spawning a child process? |
|
| Back to top |
|
|
Gentoopc
Apprentice
Joined: 25 Dec 2017
Posts: 296
|
| Posted: Thu Sep 21, 2023 11:18 pm Post subject: |
|
|
| Hu wrote: | The kernel is unlikely to suffer any particularly bad problems if fork fails. It has error handling. However, as others have described, your user processes will not take well to it.
Could you explain why you are asking? |
I plan to remove oom_keller from the kernel and not change the fork() function |
|
| Back to top |
|
|
Gentoopc
Apprentice
Joined: 25 Dec 2017
Posts: 296
|
| Posted: Thu Sep 21, 2023 11:23 pm Post subject: |
|
|
guys, the topic was not for speculation. I asked who has already encountered this or knows because of the development of the kernel, because they know exactly what it will entail. I need to know step by step what will happen if fork() is stopped on a running system. step by step , what will happen in the core ? what will happen that cannot be seen from outside? |
|
| Back to top |
|
|
Gentoopc
Apprentice
Joined: 25 Dec 2017
Posts: 296
|
| Posted: Thu Sep 21, 2023 11:27 pm Post subject: |
|
|
| eccerr0r wrote: | What do you mean?
This would sort of break a lot of stuff of course. Shell scripts would stop running properly too. |
I plan to stop the fork() function until the processes terminate. after the resources are released, resume the work of fork(). this should come to replace killer. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21918
|
| Posted: Fri Sep 22, 2023 12:57 am Post subject: |
|
|
| I've seen it before, when the system is critically low on memory. If you have a problem with the OOM killer, fix that problem. This might mean disabling memory overcommit. Categorically disabling fork, or worse, making it stall, is probably going to cause more problems than it solves. Why are you trying to disable the OOM killer? |
|
| Back to top |
|
|
Gentoopc
Apprentice
Joined: 25 Dec 2017
Posts: 296
|
| Posted: Fri Sep 22, 2023 2:38 am Post subject: |
|
|
killer's work is not always correct. sometimes it kills the wrong process. therefore, I think that the best solution would be to suspend fork() until resources are released from the work of other processes, as soon as the processes work out and the resources are released, fork() will resume. I plan to remove any killer from the kernel . this is wrong. the system should work like clockwork, if it doesn't work like that, then the killing method doesn't solve the problem. I think that everything is clear here . I want to adjust the work of fork(), if it works smart, the work of killer will not be needed. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1751
|
| Posted: Fri Sep 22, 2023 5:08 am Post subject: |
|
|
| Gentoopc wrote: | | suspend fork() until resources are released from the work of other processes |
That's certainly not going to work. Until the moment you get there, the system would already be unresponsive and it's not likely it's going anywhere further. It needs MORE resources in such situation and the only way to exit that condition is unconditional release of resources which OOM killer does, if you're lucky. I've been in situations where even OOM killer is unable to deal with the situation and resulted in unplugging the power cord.
If it was so easy, somebody should have already come up with such a solution.
Best regards,
Georgi |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3203
|
| Posted: Fri Sep 22, 2023 11:02 am Post subject: |
|
|
| Quote: | | guys, the topic was not for speculation |
You didn't give us enough details to give any definitive answers.
There may be 1 way for something to work, but possible failures are plenty.
| Quote: | | killer's work is not always correct. sometimes it kills the wrong process. |
Yes. It attempts to kill a process which has allocated a lot of memory doing little work (consumed few CPU cycles).
You can tune it by applying custom weights to your processes. E.g. sshd is quite often immune to oomk. Have a look at /proc/$PID/oom_adj
I also recall protecting databases on LAMPs with this; Apache workers are disposable, but I don't want the whole system going down.
| Quote: | | therefore, I think that the best solution would be to suspend fork() until resources are released |
So your process that attempted to fork will hang and do nothing with locked resources which could be used for something else. AKA: you're short on resources, so you'll just waste them.
This will only work in a very specific case, when you have many short-lived processes that don't allocate new memory after initializing.
Add some SWAP instead, and set swappiness to a low non-zero value. 1 will make system use it only as the last resort before OOMK kicks in. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1744
|
| Posted: Fri Sep 22, 2023 12:36 pm Post subject: |
|
|
| Gentoopc wrote: | | killer's work is not always correct. sometimes it kills the wrong process. therefore, I think that the best solution would be to suspend fork() until resources are released from the work of other processes, as soon as the processes work out and the resources are released, fork() will resume. I plan to remove any killer from the kernel . this is wrong. the system should work like clockwork, if it doesn't work like that, then the killing method doesn't solve the problem. I think that everything is clear here . I want to adjust the work of fork(), if it works smart, the work of killer will not be needed. |
If oom_killer is targeting the wrong process, particularly on a server, a better answer can be to disable the overcommit memory.
| Code: | vm.overcommit_memory=2
vm.overcommit_ratio=100
|
These settings in /etc/sysctl.d/ will force malloc to return false if there is no resources left at that moment. Decently programmed daemons can handle this but poor ones may crash.
Details on these settings are at /usr/src/linux/Documentation/admin-guide/sysctl/vm.rst (or its online equivalent). |
|
| Back to top |
|
|
Gentoopc
Apprentice
Joined: 25 Dec 2017
Posts: 296
|
| Posted: Fri Sep 22, 2023 9:13 pm Post subject: |
|
|
| szatox wrote: |
Yes. It attempts to kill a process which has allocated a lot of memory doing little work (consumed few CPU cycles).
You can tune it by applying custom weights to your processes
|
What are you guys talking about? don't you understand that you can't fix the crooked work of the kernel with scripts! of course, this is figuratively said, but the essence remains the essence, the kernel logic is built incorrectly. such a feeling that kenrel was written by children. the probability that the killer can work correctly is about 1/100. of course, I exaggerated because in fact the probability is even less, and instead of correcting the wrong logic of the kernel, you say that the killer that usually kills the wrong processes and destroys the system, and so you say that such a killer that will finish off the system if it did not collapse itself from stupidly generated processes simply does not we're going around. |
|
| Back to top |
|
|
Gentoopc
Apprentice
Joined: 25 Dec 2017
Posts: 296
|
| Posted: Fri Sep 22, 2023 9:19 pm Post subject: |
|
|
there is only one right move. this is to build the work of the kernel so that the killer is not needed. for 30 years of the kernel's existence, it would already be possible to see all the errors in its construction and fix them. but instead, they sculpt patches and props just to make it work. and as a result, they did not come up with anything better than killing processes stupidly and uncontrollably generated in the system. it's just maximum stupidity. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21918
|
| Posted: Fri Sep 22, 2023 10:04 pm Post subject: |
|
|
| I invite you to write a test case which provokes the OOM killer, then run that same test case under your proposed modification and show that your fork-stopping kernel behaves better. I expect the results will not end well, so you should ensure you can tolerate a system crash before you attempt this. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1744
|
| Posted: Fri Sep 22, 2023 10:10 pm Post subject: |
|
|
| Gentoopc wrote: | | there is only one right move. this is to build the work of the kernel so that the killer is not needed. for 30 years of the kernel's existence, it would already be possible to see all the errors in its construction and fix them. but instead, they sculpt patches and props just to make it work. and as a result, they did not come up with anything better than killing processes stupidly and uncontrollably generated in the system. it's just maximum stupidity. |
Perhaps you've not understood. Removing overcommit makes oom_killer next to impossible to activate because it was created due to overcommit (the default memory mode).
If you don't want oom_killer at all, set vm.overcommit_memory=2 |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3203
|
| Posted: Fri Sep 22, 2023 10:26 pm Post subject: |
|
|
Gentoopc, I and a few other users had an impression you fell for the X-Y problem and provided you with a total of 3 solutions which would let you either avoid triggering oomk entirely or make it non-catastrophic, but we were clearly wrong about your intentions.
Since you're appear to actually be stuck up on finding out the result of fork stopping to work rather than keeping your machine chugging, you can easily test it yourself with the single line of code below. You have been warned.
Expect your system to hang up
Last edited by szatox on Sat Sep 23, 2023 12:26 pm; edited 1 time in total |
|
| Back to top |
|
|
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 224
Location: Pennsylvania, USA
|
| Posted: Fri Sep 22, 2023 11:17 pm Post subject: |
|
|
| Gentoopc wrote: | | I plan to stop the fork() function until the processes terminate. after the resources are released, resume the work of fork(). this should come to replace killer. |
How does that prevent memory exhaustion ?
What if you have a long-running process with a memory leak ? It never forks, but slowly consumes all your memory (and hopefully the OOM killer will vaporize it).
What you have a large process, not leaking memory but attempting to solve a big problem that requires more memory than your system has ? No forks involved here, but you still run out of resources. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54453
Location: 56N 3W
|
| Posted: Sat Sep 23, 2023 10:26 am Post subject: |
|
|
fork is rarely a problem.
Systems tend to get bogged down in swapping a long time before the OOM manager kicks in.
Then the OOM only frees RAM for the kernel to continue to operate. The other option is for the kernel to panic.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9714
Location: almost Mile High in the USA
|
| Posted: Mon Sep 25, 2023 7:31 pm Post subject: |
|
|
If the machine is out of memory and you fork another process, you are still out of memory.
If the machine is out of memory and you prohibit fork another process, you are still out of memory. The existing processes can still malloc more memory and you're still screwed.
Need to get at the root of the issue. I thought the fork bomb from unscrupulous users was the initial reason for this, but now it seems not.
Is it that you're worried that make will fork a new process even under memory pressure? Should hack the userland scheduler like make to stop forking additional processes when under memory pressure, not make the kernel prohibit it. It actually works better this way when make knows that it didn't fork versus it got a child killed or fork() hangs, plus there may be a race condition when your kernel starts allowing forks to continue when they're on queue (or do you just silently fail the forks?). A usermode hack still needs to occur to take this into account and you're breaking POSIX if you silently fail.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Jimmy Jazz
Guru
Joined: 04 Oct 2004
Posts: 331
Location: Strasbourg
|
| Posted: Mon Sep 25, 2023 11:31 pm Post subject: Re: fork |
|
|
| Gentoopc wrote: | | hello forum. who can say for sure what will happen to the kernel if fork() stops spawning processes? has anyone encountered this in reality? |
increase ulimit -p 220 and ulimit -d 8192000 for instance
_________________
« La seule condition au triomphe du mal, c'est l'inaction des gens de bien » E.Burke
| Code: |
+----+----+----+
| |::::| |
| |::::| |
+----+----+----+ |
motto: WeLCRO
WritE Less Code, Repeat Often |
|
| Back to top |
|
|
Gentoopc
Apprentice
Joined: 25 Dec 2017
Posts: 296
|
| Posted: Tue Sep 26, 2023 4:13 pm Post subject: |
|
|
| eccerr0r wrote: | | It actually works better this way when make knows |
what kind of make are you talking about? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21918
|
| Posted: Tue Sep 26, 2023 6:22 pm Post subject: |
|
|
| From context, my first guess would be GNU Make, from the package sys-devel/make. It is possible, but unlikely, that eccerr0r was referring to NetBSD's make (sys-devel/bmake), Debian's version of NetBSD's make (sys-devel/pmake), or sys-devel/remake. |
|
| Back to top |
|
|
|
Kernel & Hardware
