Debian Template: qubes-core-agent.postinst causes very slow package installation

[adrelanos]

Installation of packages in Debian TemplateVM is currently very slow. To see this issue in action, open /var/lib/dpkg/info/qubes-core-agent.postinst as root and add set -x below #!/bin/bash. This is something I consider as a sanity test during development anyhow to check if everything works as expected. qubes-core-agent.postinst is called an unnecessarily high amount of times running for a very long time. For example, each time some file in /usr/share/application is changed, all the #DEBHELPER# code is invoked, that eventually includes restart of all systemd unit files, that are shipped by by the qubes-core-agent-linux package.

Proposed fix:
Consider adding an exit 0 below line 397. This would result in case of triggered to not run any #DEBHELPER# code.

I don't know yet if there are any situations, where maintainer scripts are called "internally" using action triggered, where #DEBHELPER# code is supposed to be executed. Something to ask debian-mentors.

[nrgaway]

On 14 July 2015 at 11:09, Patrick Schleizer notifications@github.com
wrote:

Installation of packages in Debian TemplateVM is currently very slow. To
see this issue in action, open
/var/lib/dpkg/info/qubes-core-agent.postinst as root and add set -x below
#!/bin/bash. This is something I consider as a sanity test during
development anyhow to check if everything works as expected.
qubes-core-agent.postinst is called an unnecessarily high amount of times
running for a very long time. For example, each time some file in
/usr/share/application is changed, all the #DEBHELPER# code is invoked,
that eventually includes restart of all systemd unit files, that are
shipped by by the qubes-core-agent-linux package.

Proposed fix:
Consider adding an exit 0 below line 397
https://github.com/QubesOS/qubes-core-agent-linux/blob/b368ffe5c690feea416274ddffcca272bcb71892/debian/qubes-core-agent.postinst#L397.
This would result in case of triggered to not run any #DEBHELPER# code.

I don't know yet if there are any situations, where maintainer scripts are
called "internally" using action triggered, where #DEBHELPER# code is
supposed to be executed. Something to ask debian-mentors.

I am aware of this issue and I actually think by "internally" calling the
triggered action is the cause. Initially this was done to avoid code
duplication but I think a better solution would be to move the code from
the triggered sections into their own functions, and just call the function
from trigger. That allows the function to also be called in the postinst
section preventing the need to call the triggered action.

[nrgaway]

On 14 July 2015 at 11:09, Patrick Schleizer notifications@github.com
wrote:

Installation of packages in Debian TemplateVM is currently very slow. To
see this issue in action, open
/var/lib/dpkg/info/qubes-core-agent.postinst as root and add set -x below
#!/bin/bash. This is something I consider as a sanity test during
development anyhow to check if everything works as expected.
qubes-core-agent.postinst is called an unnecessarily high amount of times
running for a very long time. For example, each time some file in
/usr/share/application is changed, all the #DEBHELPER# code is invoked,
that eventually includes restart of all systemd unit files, that are
shipped by by the qubes-core-agent-linux package.

Proposed fix:
Consider adding an exit 0 below line 397
https://github.com/QubesOS/qubes-core-agent-linux/blob/b368ffe5c690feea416274ddffcca272bcb71892/debian/qubes-core-agent.postinst#L397.
This would result in case of triggered to not run any #DEBHELPER# code.

I don't know yet if there are any situations, where maintainer scripts are
called "internally" using action triggered, where #DEBHELPER# code is
supposed to be executed. Something to ask debian-mentors.

I am aware of this issue and I actually think by "internally" calling the
triggered action is the cause. Initially this was done to avoid code
duplication but I think a better solution would be to move the code from
the triggered sections into their own functions, and just call the function
from trigger. That allows the function to also be called in the postinst
section preventing the need to call the triggered action.

[adrelanos]

What do you think about exit 0 after the triggered action is done?

[adrelanos]

What do you think about exit 0 after the triggered action is done?

[nrgaway]

On 14 July 2015 at 17:20, Patrick Schleizer notifications@github.com
wrote:

What do you think about exit 0 after the triggered action is done?

I'm not sure at the moment. If what I do above does not solve the speed
issue, I will give it a try.

[nrgaway]

On 14 July 2015 at 17:20, Patrick Schleizer notifications@github.com
wrote:

What do you think about exit 0 after the triggered action is done?

I'm not sure at the moment. If what I do above does not solve the speed
issue, I will give it a try.

[adrelanos]

FYI: For qubes-gui-agent-linux you do exit 0 after processing case triggered. Source:
https://github.com/QubesOS/qubes-gui-agent-linux/blob/e3b681475b6d2e3aa445326a8d49e6dbcd22028f/debian/qubes-gui-agent.postinst#L51
Not part of an argument. Just mentioning so we get this fixed/same everywhere.

[adrelanos]

FYI: For qubes-gui-agent-linux you do exit 0 after processing case triggered. Source:
https://github.com/QubesOS/qubes-gui-agent-linux/blob/e3b681475b6d2e3aa445326a8d49e6dbcd22028f/debian/qubes-gui-agent.postinst#L51
Not part of an argument. Just mentioning so we get this fixed/same everywhere.

[adrelanos]

Asked on the debian-mentors mailing list...
Okay to exit after triggers before auto generated #DEBHELPER# code?:
https://lists.debian.org/debian-mentors/2015/07/msg00314.html
Will keep you posted about answers.

[adrelanos]

Asked on the debian-mentors mailing list...
Okay to exit after triggers before auto generated #DEBHELPER# code?:
https://lists.debian.org/debian-mentors/2015/07/msg00314.html
Will keep you posted about answers.

[adrelanos]

Got one answer: "yes" (it's okay).

I am sure now. It's fine to exit 0 after processing case triggered. Also for other reason. After you have build the package, you can open and look what auto generated the #DEBHELPER# token has actually generated. You'll see that this code does not mention trigger.

To sum up... The safe fix is...
Add an exit 0 below line 397:
https://github.com/QubesOS/qubes-core-agent-linux/blob/b368ffe5c690feea416274ddffcca272bcb71892/debian/qubes-core-agent.postinst#L397

[adrelanos]

Got one answer: "yes" (it's okay).

I am sure now. It's fine to exit 0 after processing case triggered. Also for other reason. After you have build the package, you can open and look what auto generated the #DEBHELPER# token has actually generated. You'll see that this code does not mention trigger.

To sum up... The safe fix is...
Add an exit 0 below line 397:
https://github.com/QubesOS/qubes-core-agent-linux/blob/b368ffe5c690feea416274ddffcca272bcb71892/debian/qubes-core-agent.postinst#L397

[adrelanos]

Pull request:
QubesOS/qubes-core-agent-linux#1

(I've also tested this on my own machine for some time now.)

[adrelanos]

Pull request:
QubesOS/qubes-core-agent-linux#1

(I've also tested this on my own machine for some time now.)

[nrgaway]

Also fixed as mentioned in other topic #1043 (comment) :)

[nrgaway]

Also fixed as mentioned in other topic #1043 (comment) :)

[marmarek]

Implemented in (merged) marmarek/qubes-core-agent-linux#11

[marmarek]

Implemented in (merged) marmarek/qubes-core-agent-linux#11