-
Notifications
You must be signed in to change notification settings - Fork 818
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
assert (!(p & 0xffff0000)); /*where p is pid*/ #41
Comments
Platform - Azure. |
So, I've went through the source code and realized that: struct process_id {
unsigned ip;
short port;
unsigned short pid;
int utime;
}; As you can see, PID.pid is short == 2 bytes. During handshakes process_id is passed around, and it's used to guard from starting handshake with one pid and finishing it with other one. However, I don't think this would cause much trouble for mtproxies, since they don't face such a huge load as Telegram's mtfronts. Also, from what I see, mtproxy only forks as much times as So, the only problem I can see is that PIDs somehow change rapidly during those fork's, and the pid of one worker is the same as pid of another worker if you only consider last 2 bytes. That means that 65536 processes should be spawned in between of those forks, which I consider very unlikely. So, I think that this check could be omitted, and maybe |
Temporary solution is to add |
In Ubuntu Focal kernel.pid_max is raised to 4194304, this needs to be fixed ASAP. |
Yes, I have noticed that mtproto-proxy fails to launch but if you restart the OS, it launches without problems. Apparently the app receives a high PID when the OS has more than two days running. What puzzles me is why does the service break, usually before 72h. |
Workaround fix for TelegramMessenger#41
Is there any updates? Or the project was abandoned. |
Apparently, yes. I suggest just comment out the line with assertion |
It wouldn't be enough to just remove assert. Internal npid_t structure should be changed also. |
One can check my simple fix for this issue - it works perfectly at my setup (Ubuntu 20.04.4 LTS in DO Cloud). |
Your fix makes mtproxy crazy, without clients it consumes 70% of core and actually doesnt work |
Could you please provide some logs and timings within the system setup to be able check your problem. I don't this behaviour on my setup - so it's hard to understand crazyness reason. |
@heni btw the same for me - mtproxy is consuming much cpu and it doesn't work at all - proxy is unavailable, mtproxy doesn't bind to specified local port. No errors in the log |
For reducing cpu time cusuming, you can try my fork. I've changed some logic about epoll timeout, so that if you specific timeout to -1 and using multithread mode, epoll would never timeout until an event be caught. |
Hello, frends!
On my hosting when the application starts, it ends up on
assert (! (p & 0xffff0000));
in
common/pid.c:32
if I comment on this line the application is launched, but all system connection calls are terminated with the
EINPROGRESS
return code and the process consumes ~ 70% of the CPUCould you please clarify what this check makes
p & 0xffff0000
Could you clarify what this check makes
p & 0xffff0000
and what rights in the system need to be checked, because on another hosting, everything works without any noticing.And by the way, yes, the process pid> 110000, if this is important, but apparently important.
===
iqdoctor @ raccoon4x: ~ / MTProxy $ grep connect st | grep 43
connect (43, {sa_family = AF_INET, sin_port = htons (8888), sin_addr = inet_addr ("91.108.4.135")}, 16) = -1 EINPROGRESS (Operation now in progress)
connect (43, {sa_family = AF_INET, sin_port = htons (80), sin_addr = inet_addr ("149.154.162.39")}, 16) = -1 EINPROGRESS (Operation now in progress)
connect (43, {sa_family = AF_INET, sin_port = htons (8888), sin_addr = inet_addr ("91.108.4.175")}, 16) = -1 EINPROGRESS (Operation now in progress)
The text was updated successfully, but these errors were encountered: