Bug 147947

It is a broader mono issue, so it'll affect (at least) banshee and f-spot as well.  A temporary workaround for 10.1 might make sense, but this should probably be fixed at a lower level than beagle.  I'm adding Aaron (banshee) and Larry (f-spot) to the CC line, and reassigning to Miguel.

We're already running mono with "exec -a mono-beagled" but unfortunately "killall mono-beagled" doesn't work and it shows up as "mono" in top unless you press 'c'.

My prctl(2) manpage doesn't include PR_SET_NAME.  Do I just pass in a const char * for the name as the second argument?  Will that work with things like "killall"?  In what kernel version was PR_SET_NAME added?

yes, call it like

const char* name = "foo";
prctl(PR_SET_NAME, (unsigned long) name, 0, 0, 0);

I'm not sure when it was added. I added support for it in KDE on 2004-09-26. 

Just tested prctl in Banshee. It works great. I can "killall banshee" and it shows up as banshee in top and the gnome system monitor. Between "exec -a" and prctl, it seems almost all bases are covered. Would be best to have this in mono itself though.

[DllImport("libc")]
private static extern int prctl(int option, byte [] arg2, ulong arg3, 
    ulong arg4, ulong arg5);
        
public static void SetProcessName(string name)
{
    if(prctl(15 /* PR_SET_NAME */, Encoding.ASCII.GetBytes(name), 
        0, 0, 0) != 0) {
        throw new ApplicationException("Error setting process name: " + 
            Mono.Unix.Native.Stdlib.GetLastError());
    }
}

I just checked this in for many tools in beagle to CVS.

We looked at implementing this bit, the technical aspects are not hard (prctl is only one part of the equation, the other bit is actually setting the visible process name which is operating system specific).

But we ran into a larger issue, consider:

mono -O=all program.exe --arg1 --arg2

What should the command line become?

program.exe --arg1 --arg2

Or:

program -O=all program.exe --arg1 --arg2

I think that at this point, until we evaluate what are the pros and cons of the various options, Mono should not dictate a policy and leave it up to the applications. 

Regarding my managed snippet for using prctl:

Encoding.ASCII.GetBytes(name)

Should be

Encoding.ASCII.GetBytes(name + "\0")

A non-NUL-terminated process name may cause problems.

the command line has nothing to do with the process name. you want people to be able to do "killall beagle" to recover their system, and not "killall mono" (which kills zmd etc as well). 

That's the point of using prctl. But there are two issues here:

a) Make "killall beagle" work, which is accomplished using prctl. Joe has patched Beagle programs for this, I have patched Banshee.

b) Make the process listing more aesthetically pleasing, which is what Miguel was talking about. 

For instance:

"exec -a 'beagle' mono -O=all beagle.exe --arg1 --arg2"

Will show up in listings as:

"beagle -O=all beagle.exe --arg2 --arg3"

When ideally we only want to show:

"beagle --arg2 --arg3"

We don't have a solution for this. We can't just shift elements in the argv[] array, as they are statically allocated and may not fit:

"--play"
"--enqueue"
"file:///path/to/song.mp3"

Shifting that once would yield:

"--enqu"
"file:///p"

We'd have to create a new allocated array with shifted elements and then re-exec the program, and that complexity and overhead is probably not worth it.

Currently just using the prctl and exec -a solution for individual apps works well. killall works, and process listings are reasonably sane.

I'm also interested in this feature for the debugger.

beagle package which does this has been submitted.

Created attachment 114922 [details]
Zen error source properties

Created attachment 114923 [details]
Zen Touch random error on plugging-in the device

Created attachment 114924 [details]
Zen Touch timing out on synching libraries

Sorry, posted attachments to wrong bugreport; could someone with the appropriate rights please delete them?

Miguel, is this being worked on?

We do not have plans on generalizing this to Mono. 

Beagle, Banshee, F-Spot all do this now.

I'll interpret #16 from miguel as a wontfix for generalizing this.

Resolved fixed for the original bug.