Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Kai Krakow]

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

[André Hartmann]

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

[Reindl Harald]

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

[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.

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

[André Hartmann]

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