| Summary: | ConditionNeedsUpdate should ignore milliseconds | ||
|---|---|---|---|
| Product: | systemd | Reporter: | qqqqqqqqq9 <qqqqqqqqq9> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
strace /usr/lib/systemd/systemd-update-done as root
dumpe2fs /dev/mapper/etc (first half) dumpe2fs /dev/sda5 (first half) |
||
|
Description
qqqqqqqqq9
2015-04-27 12:44:02 UTC
Hmm, this is really weird. ext4 supports nsec resolution just fine normally, and s-u-d makes use of utimensat() and futimens() to apply it, which has the necessary resolution. We also apply the exact same timestamp to both /etc/.updated and /var/.updated, it's really weird that they should be different... Any chance you can invoke "strace /usr/lib/systemd/systemd-update-done" as root and attach the last 150 lines of output this generates here? is it possible that the file system uses different mount options or feature settings in the header? (the latter check with dumpe2fs) This is really weird... Created attachment 115376 [details]
strace /usr/lib/systemd/systemd-update-done as root
Hmm, so the stat() apparently indicated that the .updated file in /var was already new enough... Wich is strange... if you remove both files, and run it again, does it work then? if you run the tool multiple times ahen, does it break again? Created attachment 115377 [details]
dumpe2fs /dev/mapper/etc (first half)
Created attachment 115378 [details]
dumpe2fs /dev/sda5 (first half)
Removing the .updated-files does not help. But I think it's a problem of the underlying filesystem because touching a new file has the same problem. touch /etc/testfile 17:00 ~$ stat /etc/testfile Datei: „/etc/testfile“ Größe: 0 Blöcke: 0 EA Block: 1024 reguläre leere Datei Gerät: fe01h/65025d Inode: 901 Verknüpfungen: 1 Zugriff: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root) Zugriff : 2015-04-27 16:59:59.000000000 +0200 Modifiziert: 2015-04-27 16:59:59.000000000 +0200 Geändert : 2015-04-27 16:59:59.000000000 +0200 So, it appears that ext4 only stores ns timestamps if the inode size is >= 256. Which one of your file systems doesnt use. mke2fs is will use 128 for small file systems by default. What a crazy idea in ext4, yuck... But I figure we need to handle this somewhat nicely... Thanks i do wonder what tools like "make" do for this case though. I am not aware that there was a way to query the granularity of the timestamps of a file system unfortunately. :-( |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.