On Tue, 17.06.14 07:59, Geunsik Lim ([email protected]) wrote: > > It seems that a goal of close_all_fds() is garbage collector to guarantee > available file descriptors for new fopen() system call. > Nowadays, the modern computer system is multi-process/multi-thread scheme > more than single-process/multi-thread. > Does systemd have to care the number of "open file size"? Actually, Is this > function need for safety net?
Yes, because 1024 is the default limit per process and that is very small. Also, file descriptors are reference to resources, most importantly files but also devices, file locks, and other objects. If we keep them open, these resources stay busy, and possibly unavailable to others. > For example, > invain@u1204lgs:/opt/git-systemd$ ulimit -n > 1024 > > If Systemd does not execute the close_all_fds() functions, > What will be happened in real environment? Depends on the system and what you do. It's just a matter of cleanliness, and it's pretty much for free anyway as the thing basically becomes a NOP if no fd is open. > On the other hand, if systemd have to not close more than two file > descriptors(e.g. 5, 17, 19) for some case to release Linux distribution > based on Systemd, can we use close_all_fds(except, ***)? In this case, Do > we have to specify withclose_all_fds(except, 3 + 19)? I cannot parse this, sorry... I am really not sure why you want to get rid of close_all_fds()? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
