[RFC] Improved Linux process title support in the CLI SAPI

Hello internals.

I'm actually using proctitle extension and it's very handy because we run
like 10+ daemons written in PHP that we manage. Without it we would be lost
:) But the actual awareness of the proctitle PECL extension is very low.
Also it does not work on windows.
I'm all over the idea to add it to the core and that will be better than
current proctitle extension. Also I don't see a major effort required to
keep this thing up to date. OS'es don't just change how process titles are
set overnight, I would imagine that being huge thing to do without a very
early notice.

The RFC is superior to proctitle in every way, so i'd say go for it.
Although small on the outside, it's actually a huge thing and will allow to
actually start building some serious stuff without using some half-baked
non-maintained extensions.

My 0.02$.

Arvids.

Am 2013-02-07 14:57, schrieb Christoph Rosse:

Am 2013-02-07 14:00, schrieb Alexey Zakhlestin:

Why does this need to be in core? This could just be done as a set of
improvements to the existing PECL extension instead. I'd guess that
the number of people who require (and would use) this functionality
is very very small indeed.

well, 2 reasons:

1. it needs to be injected into main() of php_cli.c
2. it can become a good start for official "CLI" extension. CLI SAPI
   has functionality, which is specific to it and exposing it to userland
   could be useful

1. I'm not an expert on the php source code, so I can't say if this is a
   problem or not, if it really is could you explain to me why?

2. Creating an official CLI extension sounds really awesome to me but
   unless there is somebody willing to develop/maintain it I would rather
   want to have this function going into core instead of patching an old
   pecl-extension.

Forget my email above got a bit mixed up with the thread.

Addressing a bunch of comments at once:

1. I've removed is_available and renamed the set/get methods to:
   cli_process_title_set/get. I've also removed the test dependencies on pcntl
   and posix. The patch is updated: https://gist.github.com/keyurdg/4728770
2. Updated the RFC's introduction section with more concrete details about
   why this is necessary

In terms of doing this as an extension: the RFC addresses why this isn't
possible.

For folks who will not be using this feature, at worst they'll loose a few
KB of memory: the amount needed to store the original argv and the original
environ.

On Thu, Feb 7, 2013 at 2:39 PM, Christoph Rosse <crosse@2bepublished.at

wrote:

why wouldn't this go into core? setting the name of the current
php-process is definitely something everyone that develops php-cli
scripts
could use.

I use a lot of php-cli scripts and I've never seen the need. Without having
hard data to back this up, I am pretty sure that this applies to nearly all
php-cli scripts.

We should not base the decision of putting something into the core on
assumptions on how many people are going to use the feature.

Obviously we should. Whether people will use it is pretty much the most
important aspect for deciding whether or not something should be added.
Even a trivial addition is a loose for the project if nobody is going to
use it. And this is no trivial addition. This seems to be quite a bit
system dependent and uses some odd methods like overwriting argv memory.
And on that note, it also has to copy the argv data if I got that right,
which is something it has to do always and not just when people are
actually using the feature ;)

I'm not saying I'm against this feature. I'd just really appreciate it if
we could drop the good old "it doesn't matter if people are going to use
it" non-arguments and instead provide a bit more info for people like me,
who are not in the process-title-hacking business. I.e. what this is needed
for an why this is needed in core. E.g. what Arvid mentioned, that this is
useful when you are running many PHP-based daemons and want to distinguish
them. That's the kind of stuff I'd like to see in the RFC.

Regarding core/non-core. People mentioned that this is not implementable as
an extension. That can be either solved by putting it into core or by
adding the necessary API hook ;) [I'm not arguing which variant is better,
just saying that not being implementable with current core does not mean
that we can't make it implementable :)]

Thanks,
Nikita

On Thu, Feb 7, 2013 at 2:39 PM, Christoph Rosse crosse@2bepublished.atwrote:

why wouldn't this go into core? setting the name of the current
php-process is definitely something everyone that develops php-cli scripts
could use.

I use a lot of php-cli scripts and I've never seen the need. Without having
hard data to back this up, I am pretty sure that this applies to nearly all
php-cli scripts.

I think you may have glossed over the part where Keyur explained that
when running tons of Gearman workers under GearmanManager it makes
things a lot easier if we had a working way to set the proctitle. As he
explained, the pecl/proctitle way of doing it isn't sufficient because
it is likely to corrupt memory if you try to set the process title to
anything longer than 3 characters. The only way to fix that memory
corruption is to hook in earlier and that isn't something we can do from
an extension.

Note that other SAPIs have the same need. The FPM SAPI does something
similar and for similar reasons. Whenever you are running any sort of
process manager, it is super useful to be able to tell what each
individual process is doing at a particular time.

-Rasmus