[Core] Vendor setproctitle by jjyao · Pull Request #53471 · ray-project/ray

jjyao · 2025-06-02T05:05:55Z

Why are these changes needed?

Vendor setproctitle by copying its C source code and expose it to Python via Cython (the original C source code is exposed via Python C extension).

The original setproctitle has a side effect when you import it due to dvarrazzo/py-setproctitle#114 (it will change psutil.Process().cmdline() from ["python", "script.py", "--flag"] to ["python script.py --flag", "", ""]) and this PR avoids that by only initializing and changing process title when setproctitle() is called.

Related issue number

Checks

I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
I've run scripts/format.sh to lint the changes in this PR.
I've included any doc changes needed for https://docs.ray.io/en/master/.
- I've added any new APIs to the API Reference. For example, if I added a
  method in Tune, I've added it in doc/source/tune/api/ under the
  corresponding .rst file.
I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
Testing Strategy
- Unit tests
- Release tests
- This PR is not tested :(

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao · 2025-06-02T05:20:59Z

python/setup.py

        )
+    # Vendor setproctitle which is a C extension by
+    # copying the so file to the ray/private/thirdparty/ folder.
+    subprocess.check_call(


Actually why not just declare setproctitle as a default dependency of Ray? What's the drawback of it? https://discuss.python.org/t/can-vendoring-dependencies-in-a-build-be-officially-supported

Case 1: I maintain a package which is a building-block for many of our internal applications and some of our customers’ applications, so maximal compatibility is a goal. This leads to us not wanting to use many libraries, as there are conflicts this would or could introduce with the downstream applications. e.g. I don’t want to use jsonschema because we have applications which use specific versions of it.

That makes sense, but unless you depend on packages with very constrained dependencies, or you yourself depend on a very constrained version of that package, it should not be an issue.
The example you gave, jsonschema, does not have any runtime dependencies, so unless you need a very constrained version of it, depending on it should not really cause any issues.

setproctitle doesn't have dependencies so dpending on it should be just fine?

@aslonnie thoughts?

Even if I don’t need a constrained version of it today, any time it does a breaking change (major release if you use semver), I need to consider it. jsonschema recently released 4.0, so using it would put us in the position of having to support jsonschema 3.x and 4.x in the same codebase.

well, this can be a reason for vendoring.

The main reason is that, if one of those dependencies has a security
vulnerability, a new or patched version of that dependency needs to
be re-vendored and a new version of the “immutable artifact”
published/installed even if your actual project has no new changes
at all. SBoM efforts go some way toward alleviating this concern,
but it’s still an added challenge and possible delay for the end
user who is otherwise left with a steaming pile of compromised
systems. Multiply it by all of the different things you’ve installed
each of which contains vendored dependencies and the situation can
quickly become unmanageable.

This is the reason for not vendoring.

Less vendoring is better in my opinion. conda-forge has been quite successful in patching ray to declare a regular dependency without vendoring.

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

aslonnie · 2025-06-02T16:26:59Z

python/setup.py

+            "-m",
+            "pip",
+            "install",
+            "-q",


maybe add --no-deps

aslonnie · 2025-06-02T17:28:18Z

python/setup.py

+    # Vendor setproctitle which is a C extension by
+    # copying the so file to the ray/private/thirdparty/ folder.


consider put it under not os.getenv("SKIP_THIRDPARTY_INSTALL_CONDA_FORGE"): ? conda forge does not really like these kind of vendoring afaik.

cc @mattip

we really just use setproctitle and getproctitle these two functions. we can put a stub file that redirects to

you can put a stub or wrapper file that redirects to either ray._private.thirdparty or external setproctitle

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

pcmoritz · 2025-06-02T18:47:24Z

The north star for Ray Core (pip install ray) is to have zero python dependencies, so declaring it as a dependency is not an option.

The ideal would be to just set the process title in the C++ code / integrate it properly into the build system, is that an option people are considering for this?

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

…ctitle

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao · 2025-06-04T23:53:54Z

import setproctitle

   @ray.remote
   def f(x):
      assert setproctitle.getproctitle() == "ray::special_f"
      return x + 1

This test now fails because how setproctitle works. setproctitle mainly provides two methods: setproctitle() and getproctitle(). setproctitle() calls syscalls to update the process title (e.g. https://man.freebsd.org/cgi/man.cgi?query=setproctitle&sektion=3&format=html) AND store the new title in a global variable. getproctitle() simply returns the previously set title from the global variable (because there is no system call to get proc title). The issue is that now we vendor setproctitle and it's different from the one inside site-package/ so if you setproctitle via one version of the setproctitle library and try to getproctitle via another version of the setproctitle library, it won't work because they don't share the same global variable.

aslonnie · 2025-06-05T05:26:22Z

hmm.. do we want ray users to rely on setproctitle.getproctitle() to do things?

aslonnie · 2025-06-05T05:29:19Z

feels that ray core should provide an api of ray.getproctitle() and ask user to use that instead.

because getproctitle() basically is not really a thing without the global setproctitle package.

or we cannot vendor setproctitle.. we can maybe have an optional/legacy behavior to call the global setproctitle.setproctitle() when it exists, just to grandfather the old behavior.

…ctitle

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

…ctitle

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao · 2025-06-09T21:46:56Z

ci/lint/check_import_order.py

@@ -1,7 +1,7 @@
 """
 This script ensures python files conform to ray's import ordering rules.
-In particular, we make sure psutil and setproctitle is imported _after_


No need to enforce the import order for setproctitle since we vendor it and doesn't rely on sys.path anymore.

jjyao · 2025-06-09T21:49:20Z

doc/source/ray-core/miscellaneous.rst

   @ray.remote
   def f(x):
-      assert setproctitle.getproctitle() == "ray::special_f"
+      assert psutil.Process().cmdline()[0] == "ray::special_f"


This is better checking since it actually makes sure the process title is actually changed underneath while getproctitle() just returns the cached title previously set by setproctitle(). In other words, the previous check only checks that setproctitle() was called without checking if the actual process title was changed or not.

jjyao · 2025-06-09T21:51:20Z

python/ray/tests/test_actor.py

    class Foo:
        def method(self, name):
-            assert setproctitle.getproctitle() == f"ray::{name}"
+            assert psutil.Process().cmdline()[0] == f"ray::{name}"


Same reason as above, checking psutil.Process().cmdline() is better than getproctitle()

jjyao · 2025-06-09T21:52:07Z

src/ray/thirdparty/BUILD.bazel

+ray_cc_library(
+    name = "setproctitle",
+    srcs = glob(["setproctitle/spt*.c"]) + select({
+       "@platforms//os:macos": ["setproctitle/darwin_set_process_name.c"],
+       "//conditions:default": [],
+    }),
+    hdrs = glob(["setproctitle/spt*.h"]) + ["setproctitle/c.h"] + select({
+       "@platforms//os:macos": ["setproctitle/darwin_set_process_name.h"],
+       "//conditions:default": [],
+    }),
+    deps = ["@local_config_python//:python_headers"],
+    local_defines = select({
+        "@platforms//os:linux": ["HAVE_SYS_PRCTL_H"],
+        "@platforms//os:macos": ["__darwin__"],
+        "//conditions:default": [],
+    }),
+)


This is basically what setproctitle.setup.py does.

aslonnie

pretty cool!

src/ray/thirdparty/BUILD.bazel

src/ray/thirdparty/setproctitle/README

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com> Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>

**Problem** All versions of setproctitle after 1.2.3 seem to introduce significant expense when forking. This in turn results in very slow or crashing runs of ray jobs on macOs, particularly when spawning many jobs. **Solution** Looking at the code, it seems as if versions after 1.2.3 make quite a lot of changes on Darwin in order to make the process renames work properly with Activity monitor and other MacOs utilities. This... is not 'especially' important to Ray. So downgrading doesn't cost us too much. Though of course it would have been vastly preferable to rely on a non-vendored latest version, but latest versions seem to have this issue. So we can downgrade for now and come back later potentially. ## Related issues fixes #59663 **Historic Context** #53471 vendored the dependency and made a slight logic tweak in the cython binding in setproctitle.pxi. This had the benefit of fixing the cmdline parse issue described in the PR but had the downside of upgrading the library version (which now included a set of Darwin tweaks which leads to the slowdown). After this PR, the state will be that the vendored version is now old enough to not contain the activity monitor tweaks for Darwin, as well as having the changes in setproctitle.pxi. Signed-off-by: ZacAttack <zac@anyscale.com>

**Problem** All versions of setproctitle after 1.2.3 seem to introduce significant expense when forking. This in turn results in very slow or crashing runs of ray jobs on macOs, particularly when spawning many jobs. **Solution** Looking at the code, it seems as if versions after 1.2.3 make quite a lot of changes on Darwin in order to make the process renames work properly with Activity monitor and other MacOs utilities. This... is not 'especially' important to Ray. So downgrading doesn't cost us too much. Though of course it would have been vastly preferable to rely on a non-vendored latest version, but latest versions seem to have this issue. So we can downgrade for now and come back later potentially. ## Related issues fixes ray-project#59663 **Historic Context** ray-project#53471 vendored the dependency and made a slight logic tweak in the cython binding in setproctitle.pxi. This had the benefit of fixing the cmdline parse issue described in the PR but had the downside of upgrading the library version (which now included a set of Darwin tweaks which leads to the slowdown). After this PR, the state will be that the vendored version is now old enough to not contain the activity monitor tweaks for Darwin, as well as having the changes in setproctitle.pxi. Signed-off-by: ZacAttack <zac@anyscale.com> Signed-off-by: jeffery4011 <jefferyshen1015@gmail.com>

**Problem** All versions of setproctitle after 1.2.3 seem to introduce significant expense when forking. This in turn results in very slow or crashing runs of ray jobs on macOs, particularly when spawning many jobs. **Solution** Looking at the code, it seems as if versions after 1.2.3 make quite a lot of changes on Darwin in order to make the process renames work properly with Activity monitor and other MacOs utilities. This... is not 'especially' important to Ray. So downgrading doesn't cost us too much. Though of course it would have been vastly preferable to rely on a non-vendored latest version, but latest versions seem to have this issue. So we can downgrade for now and come back later potentially. ## Related issues fixes ray-project#59663 **Historic Context** ray-project#53471 vendored the dependency and made a slight logic tweak in the cython binding in setproctitle.pxi. This had the benefit of fixing the cmdline parse issue described in the PR but had the downside of upgrading the library version (which now included a set of Darwin tweaks which leads to the slowdown). After this PR, the state will be that the vendored version is now old enough to not contain the activity monitor tweaks for Darwin, as well as having the changes in setproctitle.pxi. Signed-off-by: ZacAttack <zac@anyscale.com>

**Problem** All versions of setproctitle after 1.2.3 seem to introduce significant expense when forking. This in turn results in very slow or crashing runs of ray jobs on macOs, particularly when spawning many jobs. **Solution** Looking at the code, it seems as if versions after 1.2.3 make quite a lot of changes on Darwin in order to make the process renames work properly with Activity monitor and other MacOs utilities. This... is not 'especially' important to Ray. So downgrading doesn't cost us too much. Though of course it would have been vastly preferable to rely on a non-vendored latest version, but latest versions seem to have this issue. So we can downgrade for now and come back later potentially. ## Related issues fixes ray-project#59663 **Historic Context** ray-project#53471 vendored the dependency and made a slight logic tweak in the cython binding in setproctitle.pxi. This had the benefit of fixing the cmdline parse issue described in the PR but had the downside of upgrading the library version (which now included a set of Darwin tweaks which leads to the slowdown). After this PR, the state will be that the vendored version is now old enough to not contain the activity monitor tweaks for Darwin, as well as having the changes in setproctitle.pxi. Signed-off-by: ZacAttack <zac@anyscale.com> Signed-off-by: peterxcli <peterxcli@gmail.com>

Vendor setproctitle

e467909

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao added the go add ONLY when ready to merge, run all tests label Jun 2, 2025

jjyao commented Jun 2, 2025

View reviewed changes

jjyao assigned aslonnie Jun 2, 2025

up

f48a8c1

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

aslonnie reviewed Jun 2, 2025

View reviewed changes

python/setup.py Outdated

"-m",

"pip",

"install",

"-q",

Copy link
Copy Markdown

Collaborator

aslonnie Jun 2, 2025

Choose a reason for hiding this comment

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

maybe add --no-deps

aslonnie reviewed Jun 2, 2025

View reviewed changes

up

b8e32e3

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao added 2 commits June 2, 2025 13:01

fix

795c814

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

Merge branch 'master' of github.com:ray-project/ray into jjyao/setpro…

4de68d9

…ctitle

jjyao mentioned this pull request Jun 2, 2025

[Core] Ensure Ray vendored libraries only be visible and used by Ray internal #52905

Closed

8 tasks

jjyao added 3 commits June 2, 2025 14:53

fix

e1031e2

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

fix

bef4ffd

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

up

78b04b2

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao added 8 commits June 5, 2025 11:01

Merge branch 'master' of github.com:ray-project/ray into jjyao/setpro…

4f0ff1e

…ctitle

vendor c code

331f30d

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

up

b0fad07

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

up

65d6f65

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

up

4422d85

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

Merge branch 'master' of github.com:ray-project/ray into jjyao/setpro…

76c2c14

…ctitle

up

d74d945

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

up

fc14291

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao changed the title ~~Vendor setproctitle~~ [Core] Vendor setproctitle Jun 9, 2025

jjyao added 2 commits June 9, 2025 14:31

up

49edeaa

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

up

446b9df

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao commented Jun 9, 2025

View reviewed changes

jjyao marked this pull request as ready for review June 9, 2025 22:34

jjyao requested review from a team, edoakes and richardliaw as code owners June 9, 2025 22:34

jjyao requested a review from aslonnie June 9, 2025 22:35

aslonnie approved these changes Jun 10, 2025

View reviewed changes

src/ray/thirdparty/BUILD.bazel Show resolved Hide resolved

src/ray/thirdparty/setproctitle/README Show resolved Hide resolved

comments

40ff8ab

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com>

jjyao merged commit 385e000 into ray-project:master Jun 10, 2025
5 checks passed

jjyao deleted the jjyao/setproctitle branch June 10, 2025 07:00

elliot-barn pushed a commit that referenced this pull request Jun 18, 2025

[Core] Vendor setproctitle (#53471)

29965be

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com> Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>

elliot-barn pushed a commit that referenced this pull request Jul 2, 2025

[Core] Vendor setproctitle (#53471)

32172a3

Signed-off-by: Jiajun Yao <jeromeyjj@gmail.com> Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>

jjyao mentioned this pull request Aug 15, 2025

[3/n] IPv6 support: Add Cython bindings for network utility functions #55443

Merged

8 tasks

This was referenced Jan 12, 2026

[Core] The sample code runs longer and freezes the system for about a minute on an M3 Pro after version 2.48. #59663

Closed

[Core] Disable per-task proctitle on macOS by default to avoid freezes #60053

Closed

edoakes mentioned this pull request Jan 15, 2026

[core] Downgrade vendored setproctitle to 1.2.3 #60185

Merged

		# Vendor setproctitle which is a C extension by
		# copying the so file to the ray/private/thirdparty/ folder.

Conversation

jjyao commented Jun 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why are these changes needed?

Related issue number

Checks

Uh oh!

jjyao Jun 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pcmoritz commented Jun 2, 2025

Uh oh!

jjyao commented Jun 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aslonnie commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aslonnie commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aslonnie left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jjyao commented Jun 2, 2025 •

edited

Loading

jjyao Jun 2, 2025 •

edited

Loading

jjyao commented Jun 4, 2025 •

edited

Loading

aslonnie commented Jun 5, 2025 •

edited

Loading

aslonnie commented Jun 5, 2025 •

edited

Loading