http://qs321.pair.com?node_id=11111517


in reply to Re: Setting $0 clears /proc/PID/environ too
in thread Setting $0 clears /proc/PID/environ too

In this case it wasn't me who changed it, it was Plack. It does a local $0 = something as a step of a sandboxing scheme when it loads the application code. So I don't have any say in it.

That said, there is a legitimate use case for changing the apparent process name. As perlvar suggests, it's more like a way for signaling state and displaying information than a way to hide identity.

Consider a situation where a number of identical services are running on a host, each in a different container serving a different customer. One is misbehaving, e.g. leaking memory or eating CPU. If I change $0 in them to display the customer name or container id in the process name as a fake argument, the sysadmin logging onto the host can just glance at ps's output and immediately know which of the instances is at fault. I can even display more information in the process name, like the version number, number of active connections, unprocessed items in the queue etc.

Starman, a Plack-based preforked web server also does this, as it displays "starman master" or "starman worker" in its process name(s).

Replies are listed 'Best First'.
Re^3: Setting $0 clears /proc/PID/environ too
by Your Mother (Archbishop) on Jan 17, 2020 at 10:33 UTC

    I had to give up using Starman early because of weird issues with internal port allocation (nothing I was doing) and segfaults. I had trouble with it on both OS X and CentOS. I have no idea if it will address your particular deployment issue but I went to uWSGI as my application engine several years ago and it’s been working great with nearly no oversight, on Ubuntu, CentOS, and OS X.

      Thanks for the tip! I was vaguely aware of uWSGI, but I must have dismissed it as a python thing back then. I didn't know it supported Perl out of the box.

      By the way we don't have too many problems with Starman, it does its job. One grumble I have with it is that it being a descendant of Net::Server::PreFork, it has support for dynamically scaling the number of workers, but this fact is not documented and normally it is set up to use a fixed number of workers.