Hello! I just wanted to give my view what oprofile can do more than ps. Even thought that requires large amount of CPU time & very good source code knowledge about program that someone else is running.
Basically you can put oprofile to collect data with very high frequency including callgraph. Then you have a tool reading all the data on the fly to track down the excecution of a given program. But I think there is a lot easier techniques (and less noticeable) if one already has root access. I want also point that opcontrol --stop is enough to stop data collection. So just loading oprofile kernel modules and running the daemon doesn't expose profiling data to /var/lib. But I still would like that /var/lib/oprofile/ wouldn't be world readable and ownership would oprofile:adm. That should be possible if oprofiled was made to use special user account. This could be archived with fairly simple patch to oprofiled that would jut call setuid and umask. This would cause all collect data automatically have correct permissions. (Unless root changes the the oprofile user accout somehow). Of course largest work would be testing and changes to package installation that handles the permission settings for user account. This at least would give some feeling of security for paranoid people. But of course world readable profile data might be considered as a feature. One good example could be that root is running automatic test suit in a development project. All test data is profiled to help any developer collect information for optimisation. This data later should be readable by all project members (who often shouldn't have root access to system) Everything is trade of unless someone makes this easily configurable too. Pauli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org