Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true
Am Thu, 17 Nov 2016 18:53:53 +0100 schrieb Lennart Poettering : > On Wed, 16.11.16 23:19, Pekka Sarnila (sarn...@adit.fi) wrote: > > > Well my first point was that the web page should not say > > > [...] > > I now added a small extension to this line: "(to the level the > firmware permits this)" ot clarify that we are bound by firmware > limitations for this. Well, I think here's a common misconception about what people understand, and what you would like them to understand. After reading all this I asked myself: What's the point of stable interface names anyways if it's going to change upon device add/remove? And I think that's actually the point: Name stability is not for device add/remove (in an ideal world, it would be). Your intention is to have stable names across reboots and remove races from device detection. I think this should be pointed out better. In the common case, with usual firmwares out there, names change in unpredictable ways if you swap hardware. This, of course, totally reverses what the man page says about "even when hardware is added/removed"... -- Regards, Kai Replies to list-only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
Hi Martin, Am 01.12.2016 um 10:20 schrieb Martin Pitt: Hello André, André Hartmann [2016-12-01 9:50 +0100]: So I naively created the following link structure (which works): /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service -> /mnt/writeable/systemd-timesyncd -> /lib/systemd/system/systemd-timesyncd.service But if I remove /mnt/writeable/systemd-timesyncd and reboot, the command 'timedatectl status' still reports enabled, which is unexpected. This is because systemd only really looks at the foo.wants/bar.service symlink itself -- it's actually okay for that to point into nothingness. I think this is mostly due to the fact that the actual units can be in /etc, /usr, or /run, and even move between those. The funny thing is, that foo.wants/bar.service can also point to ../baz.service, i.e. the name of the symlink does not matter. Somehow systemd seems to recognize when such a link is created and "cache" this result somewhere. In other words: once this symlink is valid, you cannot invalidate it by make it a dangling symlink, you have to remove it. Can somebody confirm this observation? And ... any other ideas how to enable/disable timesyncd? I'd like to keep as much as possible read-only, including the configurations. Thanks, Andre For example, you might have /usr/lib/systemd/system/foo.service /usr/lib/systemd/system/multi-user.target.wants/foo.service → ../foo.service and then override this with /etc/systemd/system/foo.service Then multi-user.target will still use the unit from /etc, *not* the one from /usr, even though that's where the symlink points to. In this case this is pretty obviously the correct behaviour; in your case it's admittedly confusing. I'm not entirely sure if dangling symlinks should be counted as "enabled", but this should least explain your observation. Martin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
Am 01.12.2016 um 02:36 schrieb Manuel Amador (Rudd-O): On 09/26/2016 10:31 AM, Reindl Harald wrote: Am 26.09.2016 um 11:27 schrieb Oliver Neukum: On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote: RTFM - when you don't say "nofail" it's ecpected to be crucial your entry says it's crucial That in turn raises the question why the default should be different than what is used in earlier systems because earlier systems (sysvinit) hat no concept like emergency mode as they where a lousy bunch of scripts where you ended in case of a crucial disk failing in a undefined state? because earlier systems had no concept for "nofail" or "fail" at all Yes, they did. Boot would fail if a device in fstab was set to mount on boot (option "noauto" absent) and it was not present during boot. This is precisely why nofail is the default. that's nonsesne just because common sense when "nofail" would be the default "nofail" would be useless at all and you would need a "afil" option - isn't that crystal clear? Sergei is right. RTFM which one? "man fstab" says clearly "don't report errrors if the device does not exist" which clearly implies "report errors when nofail is missing" and what should happen when something repots and erorr is pretty clear defined these days ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
Hello André, André Hartmann [2016-12-01 9:50 +0100]: > So I naively created the following link structure (which works): > > /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service -> > /mnt/writeable/systemd-timesyncd -> > /lib/systemd/system/systemd-timesyncd.service > > But if I remove /mnt/writeable/systemd-timesyncd and reboot, > the command 'timedatectl status' still reports enabled, which is unexpected. This is because systemd only really looks at the foo.wants/bar.service symlink itself -- it's actually okay for that to point into nothingness. I think this is mostly due to the fact that the actual units can be in /etc, /usr, or /run, and even move between those. For example, you might have /usr/lib/systemd/system/foo.service /usr/lib/systemd/system/multi-user.target.wants/foo.service → ../foo.service and then override this with /etc/systemd/system/foo.service Then multi-user.target will still use the unit from /etc, *not* the one from /usr, even though that's where the symlink points to. In this case this is pretty obviously the correct behaviour; in your case it's admittedly confusing. I'm not entirely sure if dangling symlinks should be counted as "enabled", but this should least explain your observation. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-timesyncd with read-only root filesystem
Hi, I'm running systemd [1] on an embbeded Linux with read-only filesystem. Due to missing realtime clock, I'd like to set the clock by either NTP or by hand. To set the time by hand with 'timedatectl set-time "time"', NTP has to be disabled, but I cannot run 'timedatectl set-ntp false' due to the read-only root filesystem. If I got it right, 'timedatectl set-ntp true/false' just creates or removes the link /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service I can create/remove the link by hand too, and after rebooting 'timedatectl status' says NTP enabled or disabled. So I naively created the following link structure (which works): /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service -> /mnt/writeable/systemd-timesyncd -> /lib/systemd/system/systemd-timesyncd.service But if I remove /mnt/writeable/systemd-timesyncd and reboot, the command 'timedatectl status' still reports enabled, which is unexpected. Do you have any hints or recommendations on this? Thanks and best regards, Andre [1] systemd 219 +PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD +IDN ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel