Dne 22. 08. 24 v 14:37 Lennart Poettering napsal(a):
On Mi, 07.08.24 13:09, Vít Ondruch (vondruch@xxxxxxxxxx) wrote:With new RPM, I hit the limit in two packages: https://koschei.fedoraproject.org/package/rubygem-abrt https://koschei.fedoraproject.org/package/rubygem-pg I have read: https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars https://stackoverflow.com/questions/34829600/why-is-the-maximal-path-length-allowed-for-unix-sockets-on-linux-108 But I still wonder why we should live with such limitation in 21st century.You don't really have to live with such a limitation. In systemd we have code that works around this limitation via O_PATH. i.e. when connect()ing you first open the socket inode with O_PATH, and then you fire the connect() specifying /proc/self/fd/<fd> as path. That always fits into the 108ch limit.
This was the workaround I have applied for the rubygem-pg: https://src.fedoraproject.org/rpms/rubygem-pg/c/8a983a989b28325fc23d650d9c2bd25409785bc5?branch=rawhideSpecifically the `export RUBY_PG_TEST_DIR=%{_builddir}/tmp` line. But not sure how would I apply your suggestion. That is something which would need to be addressed on PostgreSQL side, right (sorry, O_PATH and FDs are not my domain)?
IOW that means workaround the issue in all possible projects, where it would be likely enough to change Kernel.
Vít
bind()ing to an overly long unix socket path is also doable, but harder (since you cannot O_PATH on an inode that doesn't exist yet). The way I'd do it is via chdir() to the dir of the target path and binding to a relative path then. But chdir() is of course icky, since it's a global property of a process, hence will affect all threads. Hence, maybe do this in a short-lived forked off process. Lennart -- Lennart Poettering, Berlin
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
