RFE: Subsecond resolution of package installation time

[ppisar]

When a package is installed, an installation time (RPMTAG_INSTALLTIME) is recorded as a UNIX time in unsigned 32-bit integer. In DNF we provide tools for reporting processes whose start time predates their installation time (of all its recursive dependencies) (e.g. DNF4's needs-restarting program).

This method of comparison suffers from false negatives when the process is started in the same second as the package was installed. An example is a package which restarts its daemon in its own %post script rpm-software-management/dnf-plugins-core#590.

The cause is a rounding of the installation time to whole seconds done by time(2) syscall which is used as a time source in RPM. Provided today's machines are fast enough to install a program and start it in the same second, I conclude that it would be useful for RPM to track the installation time with a subsecond resolution.

Subsecond resolution won't fix the false negatives completely because there still be some rounding, but has a potential to diminish it significantly. E.g. gettimeofday(2) returns time with microsecond resolution.

Please consider enhancing RPM database format and RPM API to provide the installation time with an subsecond resultion. E.g. the SQLite database could gain a new column storing a microsecond remainder (defaulting to 0) from the currently stored UNIX time. And the API could gain a new tag for retrieving that remainder. This way it the enhancement would be fully compatible.

[ffesti]

The situation is actually even worse than you think. The installation of a package can spend multiple seconds. So the %pre script and a %post script can be quite some time apart. So even a more precise installation time won't solve the fact that you are using a data source that is basically unsuited for what you are trying to achieve.

I wonder if dnf could just keep timestamps of the rpm transaction callbacks.

[ppisar]

Maybe, could you clarify what time is recorded into the RPM database now? I was told that it is when the installation phase ends, before %post script is executed.

The DNF use case cannot use a time of an RPM transaction callback: It is an standalone program that has not relation to when DNF executes and RPM transaction. It should also cover cases when the package is updated with rpm tool without DNF.

[dmnks]

Maybe, could you clarify what time is recorded into the RPM database now? I was told that it is when the installation phase ends, before %post script is executed.

The timestamp is taken in between %pre and %post. Thus, my understanding is that, if a package restarts its service in %post, it's guaranteed to have a timestamp that's equal or later than the package's installation time. Likewise, if it's restarted in %pre, it's guaranteed to have it equal or earlier than the installation time. Anyway, as already mentioned by Florian, making the timestamp more granular isn't the proper solution, just a band-aid that might or might not improve the situation.

I wonder if RPM could "clamp" the timestamp so that it's one second earlier than the %pre scriptlet execution, or something like that.

[ppisar]

First I thought you seems you try to persuade me that with a discrete time measure there will be always possibility that the measured installation time and and the %post execution time fall into the same time quantum. But I'm pretty aware of it and that was the point of my request: I only asked to make the quantum small enough to make the case practically improbable. On the DNF/DNF5 side would handle the case of the same quantum as inconclusive.

But now it seems the problem is that RPMTAG_INSTALLTIME is not actually what I understand under an installation time, i.e. a time stamp taken after updating the last file of the installed package. Now it it looks like an arbitrary time stamp taken after finishing %pre and before starting %post. (Is that why Florian wrote "The installation of a package can spend multiple seconds."?). In that case would it be possible to change it? Or introduce a completely new RPM database entry attribute being better suited to my definition of the installation time?

The idea of clamping the time stamp, e.g. subtracting 1 second from the measured time stamp of %pre finish, would express "the package is was installed after this time point". I worry that would not work for my use case. I would be able to recognize processes that were started before the installation. But I couldn't tell anything about processes started after that time point. It seems that I'm more interested in the other end of the installation interval. Even a plain end of the transaction without per-package discrimination would be good enough.