Hi,
I crashed into this today too, so here's some more information :)
The underlying cause of this change appears to be the same thing
that resulted in #652026 (also in amavis). There's a pretty
complete description of it there, so I won't repeat it here.
On the bright side, it should be quite easy to fix, and is trivial
to workaround.
amavisd-new does:
$myprogram_name = $0;
Followed by later calls to do (essentially):
$0 = $myprogram_name . $something
for its various sub-processes. So it could be fixed in the amavis
code by just stripping the path components off the initial assignment
to $myprogram_name in the BEGIN {} section.
In the meantime, people who need to can set $myprogram_name to whatever
they want in the amavis config, and that will also be respected.
FWIW, I hit this trying to use the munin 'proc' plugin to monitor
amavis, and it initially choked on the '/' characters in the process
name. Unfortunately there's a synergy of sadness there which means
it still doesn't play nice with $myprogram_name = 'amavisd-new',
because that then means /proc/$pid/stat ends up with something like
'amavisd-new (ma' in it, and there's no prizes for guessing how happy
it is with the space and the paren ...
But I can set it to something like 'amavisd_process' which is 15
characters long, doesn't look totally stupid as a graph label, and
pushes the nasties out of the /stat entry too, to work around two
bugs with one kludge :)
Cheers,
Ron
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
