Skip to content

MacOS: Avoid fatal ENAMETOOLONG on SMP startup #1783

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.

Sign up for GitHub

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

Open
kinkie wants to merge 3 commits into
base: master
Choose a base branch
from
+2 −2
Open

MacOS: Avoid fatal ENAMETOOLONG on SMP startup #1783

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3e7616a
MacOS portability: shorten shm names
kinkie Apr 17, 2024
24c6cee
Merge branch 'master' into macos-shmmaps
kinkie Apr 17, 2024
b39f5c8
Merge branch 'master' into macos-shmmaps
kinkie Mar 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/MemStore.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@
#include "tools.h"

/// shared memory segment path to use for MemStore maps
static const auto MapLabel = "cache_mem_map";
static const auto MapLabel = "cache_mem";
/// shared memory segment path to use for the free slices index
static const char *SpaceLabel = "cache_mem_space";
/// shared memory segment path to use for IDs of shared pages with slice data
Expand Down
2 changes: 1 addition & 1 deletion src/Transients.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@
static const auto &
MapLabel()
{
static const auto label = new SBuf("transients_map");
static const auto label = new SBuf("transients");
return *label;
Copy link
Copy Markdown
Contributor

@rousskov rousskov Apr 17, 2024

Choose a reason for hiding this comment

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

I love the simplicity of the current solution, but it has several problems that are not visible in the PR diff. Some of them are significant. In aggregate, they call for a different solution IMO.

I speculate that the current solution does not fully address the problem because Rock cache_dirs with reasonable names will exceed the same limit. Each cache_dir map name is derived from a cache_dir database filename. Those filenames will often be much longer than "cache_mem_map"! See Rock::SwapDir::inodeMapPath().

I speculate that the current solution does not fully address the problem for Squids started with -n command line option because that option value is added to the segment name. The default service name is APP_SHORTNAME (usually "squid"), but names set on the command line can be as long as 32 characters. See service_name and Ipc::Mem::Segment::GenerateName().

The current solution introduces a new inconsistency: Some StoreMap objects still use a _map name suffix/component and some do not.

Removal of the _map suffix makes debugging more misleading. For example, the message below is related to cache_mem, but Squid is not really reading cache_mem segment or pages here. It is reading a map of those pages. There are many such debugging messages, in various important contexts.

openForReadingAt: cannot open empty entry 14914 for reading cache_mem

Finally, due to code duplication, the current changes introduce an inconsistency with debugging in CollapsedForwarding::HandleNewData() that still uses transients_map. This is very minor, of course.

I suggest a different approach. Here is a very rough sketch:

1: Undo current PR changes. We will keep the existing StoreMap labels intact.

2: Adjust Ipc::Mem::Segment::GenerateName() direct and indirect callers to supply two string parameters1 (e.g., humanId and machineId). The first string is the human-friendly segment name we currently use. No changes there. The second string will contain one or more dash-separated components: scope - subscope - subsubscope... The first component uniquely identifies StoreMap caller/context (e.g., MemStore will use scope 1; Transients will use scope 2, RockSwapDir will have scope 3 -- all coming from some new enum, of course). The subsequent ids uniquely identify scopes within that scope (e.g., RockSwapDir will have subscopes for each cache_dir directive; StoreMap will add (sub)subscope 1 for slices segment, 2 for anchors segment, and 3 for filenos segment). We need this manual ID-creation process because we cannot easily and reliably create short names from user-controlled long strings; a hash or map, for example, will not work well. It is more difficult to describe than it will look in the final code.

3: Adjust Ipc::Mem::Segment::GenerateName() to take two string parameters (e.g., humandId and machineId), and to produce (on MacOS) segment names in the following format / service_name - machineId .shm. This algorithm does not accommodate very long service names, but perhaps that is OK. I suspect we must keep the service name as a part of the name to avoid clashes among multiple Squid instances running on the same host...

4: Log (via level-2 or level-3 debugs()) the mapping between Ipc::Mem::Segment::GenerateName() humanId, machineId, and return value.

5: Use the human-friendly id parameter as Segment::theName, except when making system calls. Those system calls and corresponding error messages should use the string generated by GenerateName(), of course. We can store that generated string in a new Segment::systemName_, Segment::syscallName_ , or similar data member. This will make segment debugging cleaner and consistent across platforms, which is an improvement on top of this bug fix.

Footnotes

  1. Depending on how the code ends up looking, we may introduce a simple class to encapsulate this information. ↩

Copy link
Copy Markdown
Contributor Author

@kinkie kinkie Apr 25, 2024

Choose a reason for hiding this comment

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

Can do it, but I have a couple of questions:

  1. why waste precious characters on machineId? let's do away with the dashes. We could allocate exactly two characters for machined. Or what if we used a md5 hash? The map is printed anyway. It could also be part of the "mgr:info" report

Copy link
Copy Markdown
Contributor

@rousskov rousskov Apr 27, 2024

Choose a reason for hiding this comment

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

  1. why waste precious characters on machineId? let's do away with the dashes. We could allocate exactly two characters for machined.

Good question.

We cannot use two fixed position characters because some existing use cases use three levels.

Using three or more (as needed) positions may cover existing cases, but will limit the number of items per position to a subset of valid filename characters. Limiting the number of supported segments per level this way may be OK, but it would be more difficult for a human to interpret machine ID.

Or what if we used a md5 hash?

Using (a portion of) an md5 hash introduces collisions and destroys readability of "ls" output. It doesn't really buy us much either AFAICT.

Copy link
Copy Markdown
Contributor Author

@kinkie kinkie Mar 20, 2026

Choose a reason for hiding this comment

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

Taking this up again. Thie process you suggest seems quite complicated and not even fully certain.
I can propose an alternative, based on the assumption that humans do not normally need to look at shm segment names, so the "ls value" is very low.

  • at configure time, detect the maximum length of shm segment names
  • if is's shorter than "long enough" (say - 64 chars?), switch to alternate naming scheme
  • alternate naming scheme: "APP_SHORTNAME" +"-" + (pid % 100) + "-" progressive counter(3 chars) _ ".shm"
  • output longname - shortname map to cache.log
  • eventually also to cachemgr report (if useful)

what do you think?

Copy link
Copy Markdown
Contributor

@rousskov rousskov Mar 20, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

Taking this up again. Thie process you suggest seems quite complicated and not even fully certain.

Where do you see the uncertainty?

I can propose an alternative, based on the assumption that humans do not normally need to look at shm segment names, so the "ls value" is very low.

To save time, I am not going to comment on the above assumption at this time.

what do you think?

I see only one real/true/essential difference between the two proposals:

  • Alex: Segment X user supplies a short unique segment X ID (i.e. machineId) to GenerateName().
  • Francesco: n-th GenerateName() caller gets a segment ID based on kid PID and n.

The second proposal is simpler, but it cannot work correctly because it does not allow two users of the same segment X to agree on that segment X name. Using the same name is required for the two users to share that shared memory segment, of course. Please keep in mind that those users are in different kid processes and that the number of GenerateName() calls in a kid process varies with that kid role, current Squid configuration, and the number of Squid reconfigurations.

There are other problems with the second proposal, but the problem described above is enough to reject it, so I am not going to detail the others.

}

Expand Down
Loading