Re: [systemd-devel] systemd-timesyncd with read-only root filesystem

2016-12-09 Thread André Hartmann

Hi Michael,

Am 09.12.2016 um 12:43 schrieb Michael Chapman:

On Fri, 9 Dec 2016, Michael Chapman wrote:
[...]

You will need to use the .service extension on at least the first of
those links. systemd will only consider links in that directory that
have valid unit names. (I'm pretty sure the intermediate link's name
doesn't matter, but I wouldn't want to rely on that -- best just to
use valid full unit names everywhere.)


Oh, something else I thought of... I'm pretty sure it doesn't make sense
having a symlink to /dev/null inside a .wants directory. Really, only
the name of those links are considered. The links aren't actually
dereferenced.


I have to disagree on this, the name does not matter, the link target 
does matter (see log below, the relevant status is marked with <---).


If I create a link named foo pointing to 
/lib/systemd/system/systemd-timesyncd.service the service is enabled and 
started. If I delete the link, the service is disabled and not started. 
Everything is fine. But it requires write access to /etc.


If I create a link structure like this:

/etc/systemd/system/sysinit.target.wants/systemd-timesyncd ->
/mnt/writeable/systemd-timesyncd ->
/lib/systemd/system/systemd-timesyncd.service

the service is also started (Good).

But if I then change the structure to

/etc/systemd/system/sysinit.target.wants/systemd-timesyncd ->
/mnt/writeable/systemd-timesyncd ->
/dev/null

timedatectl still says "NTP is enabled".

And at this point I don't know how to proceed.

Best regards,
André

Log:

$ ssh root@192.168.16.14
Password:

root@apalis-imx6:~# rm 
/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service


root@apalis-imx6:~# reboot
Connection to 192.168.16.14 closed by remote host.

$ ssh root@192.168.16.14
Password:

root@apalis-imx6:~# systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service;
   disabled; vendor preset: enabled)  <---
   Active: inactive (dead)
 Docs: man:systemd-timesyncd.service(8)

root@apalis-imx6:~# timedatectl
  Local time: Fri 2016-12-09 13:20:46 UTC
  Universal time: Fri 2016-12-09 13:20:46 UTC
RTC time: n/a
   Time zone: Universal (UTC, +)
 NTP enabled: no  <
NTP synchronized: no
 RTC in local TZ: no
  DST active: n/a

root@apalis-imx6:~# cd /etc/systemd/system/sysinit.target.wants/
root@apalis-imx6:/etc/systemd/system/sysinit.target.wants# mount-rw /
root@apalis-imx6:/etc/systemd/system/sysinit.target.wants# ln -s 
/lib/systemd/system/systemd-timesyncd.service foo

root@apalis-imx6:/etc/systemd/system/sysinit.target.wants# ll foo
lrwxrwxrwx1 root root45 Dec  9 13:21 foo -> 
/lib/systemd/system/systemd-timesyncd.service


root@apalis-imx6:/etc/systemd/system/sysinit.target.wants# reboot
Connection to 192.168.16.14 closed by remote host.

$ ssh root@192.168.16.14
Warning: Permanently added '192.168.16.14' (ECDSA) to the list of known 
hosts.

Password:

root@apalis-imx6:~# systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service;
   enabled; vendor preset: enabled) <---
   Active: inactive (dead)
 Docs: man:systemd-timesyncd.service(8)

root@apalis-imx6:~# timedatectl
  Local time: Fri 2016-12-09 13:21:51 UTC
  Universal time: Fri 2016-12-09 13:21:51 UTC
RTC time: n/a
   Time zone: Universal (UTC, +)
 NTP enabled: yes   <---
NTP synchronized: no
 RTC in local TZ: no
  DST active: n/a

root@apalis-imx6:~#
___
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

2016-12-09 Thread André Hartmann

Hi Michael,

Am 09.12.2016 um 10:25 schrieb Michael Chapman:

On Thu, 8 Dec 2016, André Hartmann wrote:
[...]

Which confuses me is the inconsistency between
"systemctl status systemd.timesyncd" and "timedatectl status":

# systemctl status systemd.timesyncd
*  systemd.timesyncd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)


You've got a typo there -- the unit is called systemd-timesyncd.service,


Your'e right, I had a typo. But after checking again, I discovered the 
following:


cat /etc/systemd/system/sysinit.target.wants/systemd-timesyncd

(empty)

But systemctl status systemd-timesyncd says active (running)

The link structure is as follows:

/etc/systemd/system/sysinit.target.wants/systemd-timesyncd ->
/mnt/writeable/systemd-timesyncd ->
/dev/null

So there is no inconsistency, but timesyncd is started even if it's not 
linked from /etc/systemd/system/sysinit.target.wants


This is not what I expect.

Thanks,
André



$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service;
enabled; vendor preset: disabled)
...

(You can also just use "systemd-timesyncd", since systemctl will assume
a .service suffix.)

- Michael



--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
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

2016-12-09 Thread André Hartmann

Hi Martin,

thanks for keeping our dialog alive :)

To sum up again what I actually want to achive:

I want to use NTP after bootup by default, but in case no NTP is 
available, the user should be able to set the date and time by hand

with timedatectl. But timedatectl refuses to do so, if "NTP is enabled".

And this is my main problem: I don't know how timedatectl decides
if NTP is enabled or not.

The one and only thing I need, is to set the date by hand if necessary. 
Preferable without file write access in /etc. The configuration of most 
of our programs is fixed, and for the ones that need it, we have a 
symlink to a writeable partition. I didn't get this to work for the time 
configuration so far.



Which confuses me is the inconsistency between
"systemctl status systemd.timesyncd" and "timedatectl status":

# systemctl status systemd.timesyncd
*  systemd.timesyncd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

# timedatectl status
  Local time: Wed 2016-12-07 16:18:06 UTC
  Universal time: Wed 2016-12-07 16:18:06 UTC
RTC time: n/a
   Time zone: Universal (UTC, +)
 NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
  DST active: n/a


I don't see an inconsistency? If timedated is not running then
timedatectl can't actualy talk to it and just shows values which it
can make up by itself.


The inconsistence here is, that timesyncd is not running/dead (could not 
be started because no valid symlink to 
/lib/systemd/system/systemd-timesyncd exists) but timedatectl insists 
that NTP is enabled.


Thanks for your help,
André


___
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

2016-12-08 Thread André Hartmann

Hi Martin,

Am 04.12.2016 um 17:48 schrieb Martin Pitt:

Hello André,

André Hartmann [2016-12-01 11:20 +0100]:

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?


Not a dangling one, but you should be able to make a symlink in /etc
pointing to /dev/null. This is called "masking" and what "systemctl
mask" does, and is sort of a stronger version of "disable" (in the
sense that it will also not be started any more through Requires= and
friends).


My main problem is that I cannot disable NTP by setting
the link to /dev/null as the root partition is read-only.

And till now I don't understand how timedatectl decides
"NTP enabled: yes/no". I need a possibility to disable NTP
in case the user will set the date by hand (also enabling
it again if the user decides otherwise).

Which confuses me is the inconsistency between
"systemctl status systemd.timesyncd" and "timedatectl status":

# systemctl status systemd.timesyncd
*  systemd.timesyncd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

# timedatectl status
  Local time: Wed 2016-12-07 16:18:06 UTC
  Universal time: Wed 2016-12-07 16:18:06 UTC
RTC time: n/a
   Time zone: Universal (UTC, +)
 NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
  DST active: n/a

Any pointers here will be helpful. I assume read-only filesystems are 
common on embedded systems, so I assume somebody already run into this 
issue?!


Thanks, André

[1] systemd 219
+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
-LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID
-ELFUTILS +KMOD +IDN

--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
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

2016-12-01 Thread 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


[systemd-devel] systemd-timesyncd with read-only root filesystem

2016-12-01 Thread 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