-
Notifications
You must be signed in to change notification settings - Fork 832
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support systems with long PIDs #486
base: master
Are you sure you want to change the base?
Conversation
I now confirm that this patch 100% breaks installation on CentOS 7 and CentOS 8, at least. Nothing can connect to proxy when this patch is applied. |
Could you please attach related server logs |
@heni there are literally no logs aside from the standard logging:
After these lines the proxy is defunct and nothing can connect to it. Merely reverting your patch and updating makes things work normally. Note: testing on my fork which integrates quite a few changes from others. |
The field type in struct cannot be changed, since it is used in the protocol packets, user clients have already assumed that it is 16-bit not 32-bit. This is why the PR doesn't work for some people. I would recommend patch it this way --- a/common/pid.c
+++ b/common/pid.c
@@ -39,8 +39,7 @@ npid_t PID;
void init_common_PID (void) {
if (!PID.pid) {
int p = getpid ();
- assert (!(p & 0xffff0000));
- PID.pid = p;
+ PID.pid = (unsigned short)p;
}
if (!PID.utime) {
PID.utime = time (0); But the best solution would be to select a other 16-bit unique ID for each MTProxy process. |
Current code fails when the kernel returns PIDs >= 65536. At my system (Ubuntu/20.04.4 LTS) it happens.
This simple patch fixes the problem in my case.
Related issue: #41