Learning systemd - timedated

kcy29581 · 2012-06-05 09:07:58

Hi all,

My Arch installation is using systemd successfully after following the wiki. I'm wanting to learn more about this and I'm finding it very hard to get specific/meaningful information.

As an example, the Arch wiki states that systemd will never allow the rtc to be set as localtime. After googling, I've found that systemd now has a service for this: http://www.freedesktop.org/wiki/Softwar … /timedated. When I try to start the service I get the following, which I understand to mean that this particualr service is not designed to be installed:

[root@bolvar ~]# systemctl enable systemd-timedated.service
Warning: unit files do not carry install information. No operation executed.

- How am I to use this service?
- How/which file should I edit for this service (or any other for that matter?)

I think I'm supposed to use PolicyKit, but I do not know where to start after googling. Must I use a gui for PolicyKit, or can I use the command line?

Many thanks.

debdj · 2012-06-05 18:39:23

All you want to know about systemd.

http://www.freedesktop.org/wiki/Software/systemd
http://0pointer.de/blog/projects/systemd
http://0pointer.de/public/systemd-man/

Last edited by debdj (2012-06-05 18:41:13)

kcy29581 · 2012-06-05 20:45:29

I went through those last night. I'll try again after work and see if I can figure this out.

debdj · 2012-06-05 20:52:41

see this:
http://www.h-online.com/open/features/B … tml?page=2

Runiq · 2012-06-05 20:56:24

kcy29581 wrote:

When I try to start the service I get the following, which I understand to mean that this particualr service is not designed to be installed:
[root@bolvar ~]# systemctl enable systemd-timedated.service
Warning: unit files do not carry install information. No operation executed.
- How am I to use this service?
- How/which file should I edit for this service (or any other for that matter?)
I think I'm supposed to use PolicyKit, but I do not know where to start after googling. Must I use a gui for PolicyKit, or can I use the command line?
Many thanks.

Timedated is run automatically. As you rightly assumed, the error message you see means that the timedated service is not supposed to be enabled manually since it has no [Install] section. Instead, it is pulled in by other targets. For very exhaustive information on a unit, such as which target requires timedated to run, use "systemctl show systemd-timedated.service".

According to its freedesktop.org wiki page, you have to talk to timedated through dbus.

Also, Pinkie Pie is best pony.

Last edited by Runiq (2012-06-05 20:57:07)

kcy29581 · 2012-06-05 22:34:34

Runiq wrote:

kcy29581 wrote:
When I try to start the service I get the following, which I understand to mean that this particualr service is not designed to be installed:
[root@bolvar ~]# systemctl enable systemd-timedated.service
Warning: unit files do not carry install information. No operation executed.
- How am I to use this service?
- How/which file should I edit for this service (or any other for that matter?)
I think I'm supposed to use PolicyKit, but I do not know where to start after googling. Must I use a gui for PolicyKit, or can I use the command line?
Many thanks.
Timedated is run automatically. As you rightly assumed, the error message you see means that the timedated service is not supposed to be enabled manually since it has no [Install] section. Instead, it is pulled in by other targets. For very exhaustive information on a unit, such as which target requires timedated to run, use "systemctl show systemd-timedated.service".
According to its freedesktop.org wiki page, you have to talk to timedated through dbus.
Also, Pinkie Pie is best pony.

It's the dbus stuff that I need to teach myself now by re-reading everything

I dye my hair rainbow, so Rainbow Dash is my bestest <3

kcy29581 · 2012-06-12 05:26:44

Ok, I am truly lost. I have absolutely no idea how to edit the conf file (if it even exists) for timedated. The link in my original post says that I should "Use SetLocalRTC() to control whether the RTC is in local time or UTC". But I don't understand where I am supposed to edit/add this...

Any help would be greatly appreciated. Does systemd have it's own forum where I could ask this question?

Teho · 2012-06-12 11:22:12

kcy29581 wrote:

I have absolutely no idea how to edit the conf file (if it even exists) for timedated.

Now I don't really know anything about the subject but I don't think that timedated doesn't what you think it does. It's small daemon that applications can use to change time related settings in systemd. Why do you even want to use localtime?

kcy29581 · 2012-06-12 11:30:57

Teho wrote:

kcy29581 wrote:
I have absolutely no idea how to edit the conf file (if it even exists) for timedated.
Now I don't really know anything about the subject but I don't think that timedated doesn't what you think it does. It's small daemon that applications can use to change time related settings in systemd. Why do you even want to use localtime?

I dual boot with Windows, and would like to see if this an option to use.

Ah, so something has to call timedated and perform the actions? It's not like the ntp daemon that syncs at boot?

falconindy · 2012-06-12 12:10:22

This doesn't actually work properly in Arch yet. systemd-timedated-ntp.target would be want you want to enable, but that needs to be WantedBy and BoundBy an NTP daemon. Soon.

This is the actual (helpful) upstream page that you should read and which I'm sure debdj meant to link you: http://www.freedesktop.org/wiki/Softwar … /timedated

kcy29581 · 2012-06-12 14:38:28

falconindy wrote:

This doesn't actually work properly in Arch yet. systemd-timedated-ntp.target would be want you want to enable, but that needs to be WantedBy and BoundBy an NTP daemon. Soon.
This is the actual (helpful) upstream page that you should read and which I'm sure debdj meant to link you: http://www.freedesktop.org/wiki/Softwar … /timedated

Thanks for the answer I did notice earlier today that I could enable the service; something I could do not before. Looking forward to this being implemented!

STUART · 2012-08-25 23:12:57

So if I want my system clock to be updated by NTP and flushed back (ie. if I accidentally ran Windows and it messed up my machine's clock), what should I enable, and how does timedated relate to this?

I've enabled ntpd.service - I'm not sure if I'm supposed to do more / something else, or if ntpd.service is doing what it should (or if it used to not, but it does now, or some historical note like that.).

I only found out about timedated from seeing it on https://wiki.archlinux.org/index.php/De … ki:Systemd - I don't know what's changed since that item was crossed out.

cfr · 2012-08-26 00:54:29

@STUART

Disclaimer: I don't (yet) use systemd at all. I just started doing some reading with a view to switching this weekend (bank holiday on Monday).

I think ntpd.service is different because that has an Install section so enabling it should have been effective.

See https://wiki.archlinux.org/index.php/Nt … emd_system.

I'm not clear how systemd handles daemons. On my initscript system:

$ ps ax | grep ntp
 1249 ?        Ss     0:01 /usr/bin/ntpd -g -u ntp:ntp -p /run/ntpd.pid

but I'm not sure whether systemd handles daemons differently. (I'm wondering if it is a bit like launchd but haven't got this far yet.) However, if this did return a similar result on your machine, you would know it was working. (Just if it doesn't, don't assume something is wrong.)

But see https://wiki.archlinux.org/index.php/Nt … _correctly.

However, if you enabled any special custom config in /etc/conf.d/ntpd.conf, then I *think* that the systemd service ignores it completely.

I'm interested in whether that's true because reading the service files, it doesn't look as though many of them offer equivalent functionality to the rc.d scripts because they ignore customisations in /etc/conf.d etc. and often the defaults are different, too.

But I am sure I must be missing something because systemd is supposed to offer similar functionality as far as I know... Or is that only if you override the default service files for services somehow?

STUART · 2012-08-27 04:59:44

(I'm going to start a separate thread to address my timedated concerns and keep the focus here on teaching/learning systemd.)

The best source for understanding how systemd works and answering your questions, as linked to in debdj's post above, is reading the posts about it on Lennart's blog: http://0pointer.de/blog/projects/systemd Start with the first or second post and then work your way forward, obviously. The first few explain the basics, and the later ones usually require some knowledge gleaned from those.

You should really read through those to see if they help you answer your questions: what I'm about to write is just a clumsy attempt to recollect from them.

However, if you enabled any special custom config in /etc/conf.d/ntpd.conf, then I *think* that the systemd service ignores it completely.
I'm interested in whether that's true because reading the service files, it doesn't look as though many of them offer equivalent functionality to the rc.d scripts because they ignore customisations in /etc/conf.d etc. and often the defaults are different, too.
But I am sure I must be missing something because systemd is supposed to offer similar functionality as far as I know... Or is that only if you override the default service files for services somehow?

The defaults are often different for systemd units as opposed to the initscripts because systemd's daemonization environment has different requirements, with many old daemon behaviors (like double-forking to free from the parent shell) being unnecessary and a waste of resources in the new ecosystem. Options are added / removed to suppress / omit this behavior.

The .service definition files of systemd are essentially all the things that were in the .conf file in the rc.d system anyway: the majority of the rc.d script was generic daemon startup logic. To make the sort of changes you would have made to the .conf file, you make them to a local configuration (/etc/) copy of the service definition.

To take the long way around:

When you enable a service like ntpd with `systemctl enable ntpd.service`, what systemctl does is read that service file from the upstream, managed set of services (/usr/lib/systemd/system/ntpd.service), find the [Install] section and the target it lists being WantedBy (in ntpd's case, multi-user.target), and makes a symbolic link to that script from that Install target's .wants directory in the local configuration tree in /etc/ (/etc/systemd/system/multi-user.target.wants/ntpd.service). If I'm not mistaken, performing the former will transparently show the latter command being run (#systemctl enable ntpd.service -> ln -s /usr/lib/systemd/system/ntpd.service /etc/systemd/system/multi-user.target/ntpd.service).

This way, when systemd starts up and runs through the services as listed for the multi-user target (prioritizing /etc/ definitions over /usr/lib ones), it finds the link in the local definition of the target's wanted services to the stock ntpd definition, and reads the [Service] section of the config to see how it should run.

Now, if you want to make the service run differently, you change that link to a copy (cp instead of ln -s) in your local configuration tree, and then you edit the copy.

The reason sysvinit had separate .conf files for this, rather than having users edit the rc.d scripts directly, was because the rc.d content was managed upstream, and it was hundreds of lines long. If the user wanted to change one thing, they would have to hunt for it, and then they might end up with a file conflict if something else in the monolithic behaviors kept in the rc.d changed.

With systemd, these concerns are ameliorated. The file is significantly smaller: since the generic daemon startup logic is contained within systemd itself, a change to that doesn't affect the service file. The only things that change specific to the service are the sort of things that were kept in the .conf file already (the startup options). You don't need to worry about clobbering the upstream file, because the local changes are kept in the /etc tree, while the packager manages source files in /usr/lib.

---

You might worry that breaking the link to /usr/lib by making a copy means that you'll miss out on any changes made to the upstream service definition unrelated to your change. My own answer would be that there's hardly any room for this (there are only like 4 functional lines and you're off the baseline for 25% of them) and that whatever changes will happen probably won't have catastrophic repercussions for not replicating them, but other people are working on something to monitor for this scenario and do delta merging.

Last edited by STUART (2012-08-27 05:18:59)

falconindy · 2012-08-27 10:11:19

STUART wrote:

Now, if you want to make the service run differently, you change that link to a copy (cp instead of ln -s) in your local configuration tree, and then you edit the copy.

This is incorrect. Real unit files do not belong in the .wants directories. If you need to alter a unit file, you copy it to /etc/systemd/system, make your change, and systemctl reenable the unit.

STUART wrote:

but other people are working on something to monitor for this scenario and do delta merging.

Who are these "other people"? This is a solved problem. See systemd-delta.

Arch Linux

#1 2012-06-05 09:07:58

Learning systemd - timedated

#2 2012-06-05 18:39:23

Re: Learning systemd - timedated

#3 2012-06-05 20:45:29

Re: Learning systemd - timedated

#4 2012-06-05 20:52:41

Re: Learning systemd - timedated

#5 2012-06-05 20:56:24

Re: Learning systemd - timedated

#6 2012-06-05 22:34:34

Re: Learning systemd - timedated

#7 2012-06-12 05:26:44

Re: Learning systemd - timedated

#8 2012-06-12 11:22:12

Re: Learning systemd - timedated

#9 2012-06-12 11:30:57

Re: Learning systemd - timedated

#10 2012-06-12 12:10:22

Re: Learning systemd - timedated

#11 2012-06-12 14:38:28

Re: Learning systemd - timedated

#12 2012-08-25 23:12:57

Re: Learning systemd - timedated

#13 2012-08-26 00:54:29

Re: Learning systemd - timedated

#14 2012-08-27 04:59:44

Re: Learning systemd - timedated

#15 2012-08-27 10:11:19

Re: Learning systemd - timedated

Board footer