Skip to contentSkip to conversation

setproctitle

DISCUSSION Albert Cahalan 1 participant 1 message Aug 19, 2004

lore
Share & tools
lore
#0 lore raw
Quoted 2 lines

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.

Quoted 6 lines

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

Quoted 6 lines

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.