RE: setproctitle

[Albert Cahalan <albert@users.sf.net>]

> What happens to all the little ps (etc.) programs
> when I munge together a *really* *long* title?

Obviously, ps prints a *really* *long* title.
I suppose, given enough tasks and ps options that
cause sorting, you could run ps out of memory.

> I'd prefer a setthreadtitle(char * new_title) such
> that the individual threads in a process (including
> the master thread, and so setproctitle() function
> is covered) could be re-titled to declare their
> purposes.  It would make debugging and logging a
> lot easier and/or more meaningful sometimes. 8-)

You won't see this in ps output. To save memory
and avoid reading normally-redundant info, ps will
only read the cmdline data once for a process.

You can get the thread ID with "ps -efL", "ps -efT",
"ps -efLm", and so on. That's pretty good. Have it all:

ps -emostat,c,psr,rtprio,class,ppid,pid,tid,nlwp,wchan:9,args

> It would also let the system preserve the original
> invocation and args for the lifetime of the process
> to prevent masquerading.  You know, by default the
> title is the args, but the set operation would
> build the new title in a new kernel-controlled
> place and move the pointer.

Now, this I like.

Solaris stores the first 80 bytes of argv in the
kernel. Modifications do not show up. HP-UX stores
the first 64 bytes, and in recent releases can
also supply a kilobyte of (modified?) argv.