Dear Maintainer,

After upgrading from 10.6.0-1 to 10.7.0-3 the scripts in /etc/init.d are not
executable and libvirtd fails to start.  Easily rectified by doing chmod +x
on the scripts, after which everything works.

Also affects libvirt-daemon-log (virtlogd), libvirt-daemon-common
(libvirt-guests) and possibly others which I do not use.

This seems weird, since the executable bit is present in the package
itself:

  $ dpkg-deb -x libvirt-daemon_10.7.0-3_amd64.deb .
  $ ls -l etc/init.d/libvirtd
  -rwxr-xr-x 1 abologna abologna 6136 Sep 16 21:41 etc/init.d/libvirtd

I have personally tested upgrades from 10.6.0-1 to 10.7.0-3 on hosts
using sysvinit and openrc instead of systemd to ensure that things
would work as expected in those scenarios, and I never encountered a
scenario like the one you're describing.

Did you customize the init scripts? We have some logic to carry
existing customizations over, and it might have gotten confused
somehow, though it should just move files around so I can't imagine
the executable bits getting lost in the process.

Any other local customizations that might be relevant?

I have not customized the init scripts.

I upgraded another computer from 10.2.0-1 to 10.7.0-3 and the same thing
happened.  Then I downgraded the packages to 10.6.0-1 and re-upgraded,
but this time the executable bits stayed.  Puzzled by this I did some
investigation and noticed in dpkg.log that my downgrade had marked
libvirt-daemon-system-sysv as manually installed so it didn't get
removed in the re-upgrade (it's now a transitional package and not
needed).  I did another downgrade, marked the package as automatically
installed (using aptitude as I usually do), and upgraded again.  The
executable bits were gone.

I had run aptitude under strace to capture what it does (perhaps a bit
of a sledgehammer, but it's the tool I know), so I went digging into the
log.  This revealed that the postrm script for
libvirt-daemon-system-sysv does a chmod -x on the various init scripts
that used to belong to that package.  Later on, when dpkg is replacing
the init scripts with the new versions, it appears to retain the modes
of the existing files.

The key detail appears to be the removal of libvirt-daemon-system-sysv
before most of the packages are upgraded.  If the obsolete sysv package
is upgraded to the transitional version instead, then the exec bits are
not touched.

Attached are excerpts from dpkg.log and the aptitude trace (all syscalls
involving /etc/init.d/libvirtd plus the calls which spawned those
processes).  I hope this plus my analysis above is enough to reproduce
the issue and come up with a solution.  I'm hesitant to attach the full
files to a public bug report out of fear that they contain sensitive
details, but let me know if you want me to send them privately or if you
need any other information.