The default commit title when installing new packages is:
committing changes in /etc made by "/usr/bin/bash"
Instead of referencing the proper package manager process (pacman in my case) This change fixes it:
--- a/etckeeper/post-install.d/50vcs-commit
+++ b/etckeeper/post-install.d/50vcs-commit
@@ -4,9 +4,7 @@ set -e
pl="/var/cache/etckeeper/packagelist"
# Parent process is etckeeper
-# (Only procps ps is currently supported, others will fail,
-# so this may end up empty.)
-ETCKEEPER_PID=$( ps --no-headers -o ppid "${PPID}" 2>/dev/null | sed 's/^ *//' )
+ETCKEEPER_PID=${PPID}
# Find the parent of etckeeper and get the command line of the process
if ! [ -z "${ETCKEEPER_PID}" ]; then
So that the commit title is now proper, eg.:
committing changes in /etc made by "pacman -S minidlna"
Will you include this fix? Or is it expected that I open a pull request? Not sure how it's done on this site as I'm not familiar with it...
I took at look at what's happening here. I see this kind of process tree when running etckeeper post-install by hand:
And
ETCKEEPER_PIDis set to 397909 andETCKEEPER_PPIDto 397908. Which is indeed kind of wrong in this case. Your patch fixes this.However, when using
apt-get installon Debian, the current code actually makes it do the right thing, and report eg "committing changes in /etc made by "apt-get install foo". In that case, the process tree is like this:With your patch it will pick 400895 as
ETCKEEPER_PPID. Which technically, it is. But that is not the command that the user ran, it's a hook script that apt is configured to run, in order to run etckeeper post-install.So in order to apply your change, this change would also be needed:
But the same kind of change would also need to be made to other package managers' hook scripts.
This is making me start to wonder if all this complexity is needed at all. There is an alternative message it can used, "committing changes in /etc after $HIGHLEVEL_PACKAGE_MANAGER run" which avoids this complexity and should be fine. This business of walking the process tree is a fairly recent addition and is buggy, so why do it.
On the third hand, it is pretty nice, when it works, to see the actual package manager command line in the commit message.
I guess what we could do is vary how
ETCKEEPER_PPIDis determined based onHIGHLEVEL_PACKAGE_MANAGER. And only use it for the message when it's a package manager we know how to get the pid of. Which right now, for me, is only apt..Were you using pacman, or pacman-g2? I guess pacman since it looks like it probably exec's etckeeper without any
sh -cprocess.joey, thanks for the feedback, I understand now why it was implemented that way. I was using pacman not pacman-g2. For reference here is how a process tree looks like with pacman:
Perhaps this could be done in a more generic way by traversing the parents until HIGHLEVEL_PACKAGE_MANAGER is found, I'll try to play with that.
Here is what I came up with:
Seems to work for me.
What it does is get the process tree of current process, reverse order, grep for HIGHLEVEL_PACKAGE_MANAGER to get the pid of it. If that fails it continues with the old method. Then it gets the command line of the found process. Not sure if dependency on pstree is something that is a problem or not...