Re: [systemd-devel] ConditionNeedsUpdate date comparison
Hi, On Tue, Jan 27, 2015 at 1:35 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 26.01.15 14:00, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, condition_test_needs_update() wants the timestamp of /usr to be newer than what is being checked. Is there a reason why we don't check for /usr != Condition.parameter? Well, when I hacked that up, I didn't think of this case. What are you saying ConditionNeedsUpdate=/usr is supposed to even mean? We are not on the same page. I never meant ConditionNeedsUpdate=/usr. Not that we explicitly document that /etc and /var are the only valid parameters currently (because we only manage those stamp files with systemd-update-done.service). Hence, ConditionNeedsUpdate=/usr is undefined currently, and it's not clear to me what is should mean? It makes sense to check for /usr Condition.parameter in a package managed linux but our embedded system is upgrading the entire /usr partition. ConditionNeedsUpdate=/etc is working fine when we upgrade our image but it fails when we downgrade it since the timestamp of /usr is older than /etc/.updated. Well, this stuf is not intended to support downgrades. I don't think that can ever work... But anyway, I don't really understand what you are trying to say I must admit. Could you please elaborate? Sure. Pretty much what I am saying is we wan't to use ConditionNeedsUpdate=/etc for downgrade case. Why do you think it won't work? Instead of IF time(/usr) time(/etc/.updated), we can check IF time(/usr) != time(/etc/.updated). Umut Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ConditionNeedsUpdate date comparison
On Tue, 27.01.15 11:17, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Well, this stuf is not intended to support downgrades. I don't think that can ever work... But anyway, I don't really understand what you are trying to say I must admit. Could you please elaborate? Sure. Pretty much what I am saying is we wan't to use ConditionNeedsUpdate=/etc for downgrade case. Why do you think it won't work? Well, it's hard to know in advance what the future will bring, hence it's difficult to have the right triggers in place to run when something from the future is downgraded... Instead of IF time(/usr) time(/etc/.updated), we can check IF time(/usr) != time(/etc/.updated). Ah, I see. Well, I figure we could change this. I do wonder though if this might be a problem with file systems that do not store timestamps as accurately (for example fat has a 2s granularity), where we might not be able to apply the precise timestamps from /usr to /var, and thus would end up running the conditioned unit every single boot? But well, I figure most modern file systems have usec granularity, hence I'd accept a patch to change this to != I figure... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ConditionNeedsUpdate date comparison
Hi, condition_test_needs_update() wants the timestamp of /usr to be newer than what is being checked. Is there a reason why we don't check for /usr != Condition.parameter? It makes sense to check for /usr Condition.parameter in a package managed linux but our embedded system is upgrading the entire /usr partition. ConditionNeedsUpdate=/etc is working fine when we upgrade our image but it fails when we downgrade it since the timestamp of /usr is older than /etc/.updated. Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ConditionNeedsUpdate date comparison
On Mon, 26.01.15 14:00, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, condition_test_needs_update() wants the timestamp of /usr to be newer than what is being checked. Is there a reason why we don't check for /usr != Condition.parameter? Well, when I hacked that up, I didn't think of this case. What are you saying ConditionNeedsUpdate=/usr is supposed to even mean? Not that we explicitly document that /etc and /var are the only valid parameters currently (because we only manage those stamp files with systemd-update-done.service). Hence, ConditionNeedsUpdate=/usr is undefined currently, and it's not clear to me what is should mean? It makes sense to check for /usr Condition.parameter in a package managed linux but our embedded system is upgrading the entire /usr partition. ConditionNeedsUpdate=/etc is working fine when we upgrade our image but it fails when we downgrade it since the timestamp of /usr is older than /etc/.updated. Well, this stuf is not intended to support downgrades. I don't think that can ever work... But anyway, I don't really understand what you are trying to say I must admit. Could you please elaborate? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
