Skip to content

Conversation

@flynn1973
Copy link
Contributor

Ticket: CFE-3625
Changelog: Title

@flynn1973 flynn1973 changed the title Increase Filedescriptor Limit to a more contemporary Value CFE-3625: Increase Filedescriptor Limit to a more contemporary Value Apr 21, 2021
@olehermanse
Copy link
Member

@cf-bottom please test this in our Jenkins CI system :)

@cf-bottom
Copy link

Copy link
Contributor

@vpodzime vpodzime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me otherwise.


static pid_t *CHILDREN = NULL; /* GLOBAL_X */
static int MAX_FD = 128; /* GLOBAL_X */ /* Max number of simultaneous pipes */
static int MAX_FD = 8192; /* GLOBAL_X */ /* Max number of simultaneous pipes */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, big hammer approach. :) I'm not quite sure 8192 child processes (or even 4096) running at the same time is feasible. What about 2048?

Copy link
Contributor Author

@flynn1973 flynn1973 Apr 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:) yeah, maybe a little bit overstated, i like to live dangerously. 2048 should be enough. i am trapped in AIX and big machine thinking.

Copy link
Member

@nickanderson nickanderson Apr 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to suggest 640k

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm...basically i can patch this locally, as i am constantly building cfengine rpms for aix. NorthernTechHQ/libntech#130 looks very "promising" to me, and i dont want to fire up a "numbers" flamewar :-). this problem seems to be a isolated thing (only me) anyway. nobody is doing stupid stuff like me g

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

128 is definitely a very low and totally artificial limit. 2048 should be fine for everybody. 😉

@vpodzime
Copy link
Contributor

Just a note: I'm currently working on NorthernTechHQ/libntech#130 which should be a better long-term solution for this and many other similar problems. Having said that, we should definitely make this simple change first.

Co-authored-by: Ole Herman Schumacher Elgesem <olehermanse@users.noreply.github.com>
@vpodzime
Copy link
Contributor

@flynn1973 could you please squash the commits? Thanks!

olehermanse and others added 4 commits April 27, 2021 09:03
No changelog entry since this memory is not really leaking,
it's just not cleaned up properly right before an exit().

Changelog: None
Ticket: CFE-3431
Signed-off-by: Ole Herman Schumacher Elgesem <ole@northern.tech>
Also added acceptance test.

Changelog: unless can now be used with custom promise types
Ticket: CFE-3431
Signed-off-by: Ole Herman Schumacher Elgesem <ole@northern.tech>
@flynn1973 flynn1973 closed this Apr 27, 2021
@flynn1973 flynn1973 deleted the CFE-3625_File_descriptor_of_child_higher_than_MAX_FD branch April 27, 2021 07:33
@flynn1973
Copy link
Contributor Author

superseeded by #4615

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

5 participants