You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My intent when I introduced the templating system for naming groups was that .ExeFull would yield the fully-qualified path to the executable. In practice it was implemented by looking at /proc//cmdline (a NULL-delimited list of strings which corresponds to argv from the process' perspective) and taking the first element of the list. .ExeBase is then the basename of that.
I knew that a process can write to its argv to change what ps reports, but I somehow didn't think about the implications for .ExeFull while I was implementing it. If the process decides to change its argv then we're at the mercy of what it writes. It may even introduce spaces, which would never occur naturally since they should be replaced by NULLs.
I'm reluctant to change the existing behaviour because it may break existing configurations. One idea I had was to introduce a new 'exe' label which would have the value in /proc//exe, but we can't assume that all members of a namegroup would share the same executable. It'll have to be a new field in the structure given to the template engine. Unfortunately .ExeFull is what it really ought to be called, but as I say, I don't want to break existing setups by changing its behaviour. I'm open to naming suggestions. If I don't hear anything better I'll go with .RealExe.
The text was updated successfully, but these errors were encountered:
The use of .ExeBase and .ExeFull cause huge cardinality explosion when dealing with Chromium (and Electron) apps, which all seem to rewrite argv[0] to be space delimited.
Configuration like this helps, but needs to be configured for each new electron app.
My intent when I introduced the templating system for naming groups was that .ExeFull would yield the fully-qualified path to the executable. In practice it was implemented by looking at /proc//cmdline (a NULL-delimited list of strings which corresponds to argv from the process' perspective) and taking the first element of the list. .ExeBase is then the basename of that.
I knew that a process can write to its argv to change what ps reports, but I somehow didn't think about the implications for .ExeFull while I was implementing it. If the process decides to change its argv then we're at the mercy of what it writes. It may even introduce spaces, which would never occur naturally since they should be replaced by NULLs.
I'm reluctant to change the existing behaviour because it may break existing configurations. One idea I had was to introduce a new 'exe' label which would have the value in /proc//exe, but we can't assume that all members of a namegroup would share the same executable. It'll have to be a new field in the structure given to the template engine. Unfortunately .ExeFull is what it really ought to be called, but as I say, I don't want to break existing setups by changing its behaviour. I'm open to naming suggestions. If I don't hear anything better I'll go with .RealExe.
The text was updated successfully, but these errors were encountered: