Debug Session Druid truncates process/progress group names to 15 char I found this while writing automated GUI tests - I'm not sure of this has any functional impact - the Druid truncates the names of processes to (15) characters. So, gnome-screensaver becomes gnome-screensav (The other Frysk GUIs display the same truncated names.)
The truncation is due to the kernel reporting only the first 15 chars of the process name in /proc/PID/stat Possible workaround - instead of the truncated process name, display information from ps in this form: 8456 /usr/lib/firefox-1.5.0.2/firefox-bin -UILocale en-U
It looks like the 15-char limit is imposed by the kernel - note the following from the killall manpage: If a command name is longer than 15 characters, the full name may be unavailable (i.e. it is swapped out). In this case, killall will kill everything that matches within the first 15 characters. In order to debug a failure, a Frysk user will probably need both the process name and target executable directory path - they may not match. So - we should provide both via frysk.
Another point of reference, the Gnome 'System Manager' refers to process names, but I think displays the name of the running executables, as they are more than 15 char long.
After investigation, these are the findings. The limit on the process name is in the /proc/$$/stat file, and following on, the kernel. On consultation with other engineers, this is a historical feature and unlikely to be changed. Also, it was pointed out that it is limited more than 15 characters due to encoding and stack limitations. James Antill noted the reference for this was: fs/proc/array.c:task_name(). The full stucture is also encoded in the exe structure of proc, and this api is provided through frysk-core with Proc.getExe(). However this is a privileged operation, and is not accessible in all scenarios. The last area to look at was getCmdLine which accesses the cmdline file in /proc/$$/cmdline. This seems to be the best compromise, and we can extract the executable file -> process map here. .getCmdLine[0] provides the full path. Looking forward, multiple user assigned columns is the way forward, but for the immediate future extracting the pathless exe name from cmdLine by doing something like: exeName = new File(proc.getCmdLine{}[0]).getName() would work (with more null/error checking than in the above code ;)
20
2006-05-26 Sami Wagiaalla <swagiaal@redhat.com> * datamodels/FlatProcObservableLinkedList.java: now using getNiceExecutablePath instead of getFullExecutablePath. * SessionProcTreeView.java: Added displaying of executable path of selected proc in the status bar. * MainWindowStatusBar.java: New file. Handle for the statusbar. * GuiProc.java: Added getNiceExecutablePath which filters out all strange output of getExe() (part of fix for 2663). 2006-05-26 Sami Wagiaalla <swagiaal@redhat.com> * sessions/DebugProcess.java: using getNiceExecutablePath instead of getFullExecutablePath. * glade/procpop.glade: Added a status bar. * druid/CreateFryskSessionDruid.java: using getNiceExecutablePath instead of getFullExecutablePath.