Closed Nerahikada closed 1 year ago
I use the deepl translation.
It seems that pmmp does not call (ThreadManager)->stopAll()
when stopped by "Forcing server shutdown".
This problem is not replicated when stopping with the stop command.
In the case of "Forcing server shutdown", "Stopping other threads" is not performed as compared to a normal shutdown.
This problem does not occur with \Thread
by itself.(without pmmp)
https://github.com/pmmp/PocketMine-MP/blob/237c2866e0d2988857a8f6423cae4e8291832099/src/Server.php#L1675-L1682 https://github.com/pmmp/PocketMine-MP/blob/0234d821f5a9bba38d65fafd8fede54742dc8e4a/src/PocketMine.php#L306-L315
I'm not able to reproduce this using WSL2.
I'm not able to reproduce this using WSL2.
Did you start the server with the loop flag enabled?
I'm not able to reproduce this using WSL2.
Did you start the server with the loop flag enabled?
Yes. The script isn't able to influence anything within PM, so it doesn't make any difference.
When the server is started with loop enabled, the group process ID of the PHP process will be that of bash. Therefore, the server will not terminate because it is trying to kill a group process ID that does not exist.
$ pstree -acutspng
init,1,
├─{init},6,
├─init,7,7
│ └─init,8,7
│ └─bash,9,9,user
│ └─bash,6432,6432 ./start.sh -l
│ └─php,6435,6432
│ ├─{php},6488,6432
│ ├─{php},6489,6432
│ ├─{php},6537,6432
│ ├─{php},6538,6432
│ ├─{php},6539,6432
│ ├─{php},6540,6432
│ └─php,6541,6432 ...
└─init,222,222
└─init,223,222
└─bash,224,224,user
└─pstree,6543,6543 -acutspng
As I said, I tested this myself, it doesn't reproduce. This must be specific to whatever distro you're using.
I have had the same issue on ubuntu but same does not seem to exist on Mac
When subprocess is set to true, server not killing actually with right PID
When the server is started with loop enabled, the group process ID of the PHP process will be that of bash. Therefore, the server will not terminate because it is trying to kill a group process ID that does not exist.
$ pstree -acutspng init,1, ├─{init},6, ├─init,7,7 │ └─init,8,7 │ └─bash,9,9,user │ └─bash,6432,6432 ./start.sh -l │ └─php,6435,6432 │ ├─{php},6488,6432 │ ├─{php},6489,6432 │ ├─{php},6537,6432 │ ├─{php},6538,6432 │ ├─{php},6539,6432 │ ├─{php},6540,6432 │ └─php,6541,6432 ... └─init,222,222 └─init,223,222 └─bash,224,224,user └─pstree,6543,6543 -acutspng
It does exist. I tested it on WSL2 and got the exact same behaviour, and it terminates itself just fine.
This must be some specific behaviour to the distro or version thereof you're using.
Reproduced in Ubuntu 20.04.4.
Autopsy: The server assumes that it has its own process group with GID = -PID. However, this isn't the case when the server process is directly invoked from bash - it belongs to the same process group as bash.
Using the actual GID via getmygid() is also not an option, because that would also terminate the bash process responsible for the loop.
Fixed by 9b43ddecb.
Issue description
Only under certain conditions, threads do not terminate and the server does not terminate forever.
Steps to reproduce the issue
OS and versions
Plugins
Requires a plugin that starts a thread that extends the
pocketmine\thread\Thread
class.Crashdump, backtrace or other files