[StrangePan][2.1.20][macOS] Authentication fails when HTTPS socket reaches FD 1024 with many ZIP mods

[z8ricky]

Factorio version: 2.1.20 (build 87512, mac-arm64, Steam, Space Age)
OS: macOS 27.0.0
Hardware: Apple M4 Pro


Summary

Factorio authentication reliably stops working when enough ZIP mods are present in the mods directory for the HTTPS connection to receive file descriptor 1024.

The mods do not need to be enabled.

In my reproducible test:

Code: Select all

555 ZIP mods -> authentication works
556 ZIP mods -> authentication fails

In the failing case, lsof shows the HTTPS connection at FD 1024.

Removing one ZIP makes authentication work again. Adding it back makes it fail again.


Reproduction

I have a large collection of ZIP mods in the mods directory. Almost all of them are disabled; only the official mods are enabled.

I found a reliably reproducible working/broken configuration.

With 555 ZIP files present:

Code: Select all

555 ZIPs -> works

I then add one additional valid ZIP mod:

Code: Select all

what-items-do-i-have_1.4.3.zip

After restarting Factorio:

Code: Select all

556 ZIPs -> authentication fails

I remove only that ZIP and restart:

Code: Select all

555 ZIPs -> authentication works again

I add the same ZIP again and restart:

Code: Select all

556 ZIPs -> authentication fails again

I reproduced this multiple times.


What happens

In the failing configuration, the verbose log shows Factorio attempting:

Code: Select all

Downloading https://auth.factorio.com/tls-check/success

After exactly 60 seconds:

Code: Select all

CURL failed: code:28
Connection timed out after 60000 milliseconds

Factorio then attempts:

Code: Select all

https://auth.factorio.com/api-steam-login?api_version=6

This also times out after 60 seconds.

Eventually:

Code: Select all

Failed to reach auth server: code(520) message(Connection timed out after 60000 milliseconds)

So the problem already occurs during TLS/auth HTTP communication.


File descriptor observation

I captured

Code: Select all

lsof

while Factorio was in the failing state.

The HTTPS connection is assigned FD 1024:

Code: Select all

factorio ... 1024u IPv4 ... TCP 192.168.110.40:63641->104.26.14.88:https (CLOSE_WAIT)

The descriptors immediately around it are:

Code: Select all

1018  main-menu.ogg
1019  wind.ogg
1020  ValveIPCSHM
1021  world_base_wind.ogg
1022  unix socket
1023  unix socket
1024  HTTPS socket
1026  NPOLICY
1027  com.apple.netsrc
1028  unix socket

Factorio also keeps two open descriptors for many ZIP mods. For example, in the attached lsof output:

Code: Select all

waterfill-2_1.0.3.zip          -> FD 1004 and 1005
what-items-do-i-have_1.4.3.zip -> FD 1006 and 1007

With the smaller working configuration, the HTTPS sockets were below the 1024 boundary (FD 1021/1022).

The FD 1024 boundary therefore appears to be the important difference between the working and failing configurations.


This does not appear to be caused by what-items-do-i-have

The same mod works when fewer ZIP files are present.

I also tested many different subsets of the mod collection. Different subsets can reach the failure at different ZIP counts.

Therefore, the important factor appears to be the number of open file descriptors rather than this particular mod or a specific number of ZIP files.


Expected behavior

Authentication and other HTTP networking should continue working when enough local ZIP mods are present that a network socket receives a file descriptor >= 1024.


Possibly related report

This appears very similar to the previously reported issue:

Code: Select all

[2.0.45] No multiplayer connectivity after 620 distinct mods

which was related to file descriptors exceeding FD_SETSIZE / select() limits.


Attachments

• factorio-current-BROKEN-VERBOSE.log — verbose log from the failing run
• factorio-BROKEN-lsof.txt — lsof captured while Factorio was in the failing state
• screenshot of the authentication error

I can also provide the exact mod collection or try to create a reduced/synthetic reproduction if needed.

[Rseding91]

This may be a won't-fix given it seems the issue is within the CURL library and I'm not sure if it's something we can/want to address. I'll pass it along to the Mac person.

[Rseding91]

This should now be fixed for the next release.