assert (!(p & 0xffff0000)); /*where p is pid*/

[iqdoctor]

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 CPU

Could 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)

[iqdoctor]

Platform - Azure.

[stek29]

So, I've went through the source code and realized that:
pid_t on most platforms is int == 4 bytes.

struct process_id {
unsigned ip;
short port;
unsigned short pid;
int utime;
};

As you can see, PID.pid is short == 2 bytes.
Doing assert (! (p & 0xffff0000)) ensures that PID fits in those 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 -M arg says, and that happens in pre_init.

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 pids after all forks should be checked that for any x and y in pids (x & 0xffff) != (y & 0xffff) where x != y.

[shadowlmd]

Temporary solution is to add kernel.pid_max=65535 to /etc/sysctl.conf, that should be fine for most setups.

[Feliksas]

In Ubuntu Focal kernel.pid_max is raised to 4194304, this needs to be fixed ASAP.

[HugoFlorentino]

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.

[ww898]

Is there any updates? Or the project was abandoned.

[ikigai-gh]

Is there any updates? Or the project was abandoned.

Apparently, yes. I suggest just comment out the line with assertion

[heni]

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.

[heni]

One can check my simple fix for this issue - it works perfectly at my setup (Ubuntu 20.04.4 LTS in DO Cloud).
#486

[AMajor-C]

One can check my simple fix for this issue - it works perfectly at my setup (Ubuntu 20.04.4 LTS in DO Cloud). #486

Your fix makes mtproxy crazy, without clients it consumes 70% of core and actually doesnt work
// CentOS 8 Stream

[heni]

One can check my simple fix for this issue - it works perfectly at my setup (Ubuntu 20.04.4 LTS in DO Cloud). #486

Your fix makes mtproxy crazy, without clients it consumes 70% of core and actually doesnt work // CentOS 8 Stream

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.

[D13410N3]

@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

[YanceyChiew]

... - mtproxy is consuming much cpu ...

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.