On Mon, Nov 28, 2016 at 6:29 AM, Igor.Podoski@xxxxxxxxxxxxxx
<Igor.Podoski@xxxxxxxxxxxxxx> wrote:
>> > I guess we could:
>> > * Switch the logic to try resolving argv[0] and only use
>> > proc/self/exe if we can't find argv[0]?
>> > * Create a link to /proc/self/exe named ceph-mds, and exec that?
>>
>> We could also check if argv[0] is 'exe' and, if so, rewrite it so that the ps
>> output shows ceph-mds...
>
> For ps/pgrep/pkill it'll work, but 'top' reports process name differently and you'll see 'exe' there. I think this is because 'ps' is looking on command line and 'top' on something else in procfs. You need to run also prctl(PR_SET_NAME, argv[0]) shortly after process starts. This could be a race condition, when system will be under big load, for a moment process name would change from 'ceph-mds' to 'exe' and then back to 'ceph-mds', pid will remain the same but some third party monitoring software could be confused (depends how they check the process name).
>
> I'm not sure, but I think you could pass argv again here, then respawn will short to:
> execv("/proc/self/exe", argv);
>
> And process name will be kept, since first start will set argv[0] and passing argv to execv + prctl will propagate it.
The process name (/proc/self/comm) is the first argument to execve:
https://github.com/torvalds/linux/blob/master/fs/exec.c#L1691-L1713
and
https://github.com/torvalds/linux/blob/master/fs/exec.c#L1296
Changing argv[0] will not help.
The only options I'm aware of to fix this are (a) change the first
argument to execve (and use a symlink as John suggested) or (b) use
prctl at startup.
Probably (b) is more palatable and maybe something we'd want to
unconditionally set to the "ideal" name of the exectuable. In this
case, that would be "ceph-mds".
--
Patrick Donnelly
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
