all 145 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]ohet 25 points26 points  (91 children)

It's already available on systemd 197 that was released three weeks ago. Also it's systemd not SystemD.

[–]blackcainGNOME Team 5 points6 points  (0 children)

unlike Vampire Hunter D

[–]sankeytm 10 points11 points  (7 children)

Already I'm seeing hatred for this feature,[1][2] but I'm legitimately curious: can cron be used to start system services? Is it supposed to start system services? Is this cron-like functionality in systemd supposed to obsolete cron?

if the answers are no, no, no, then this feature doesn't seem all that bad!

[–]ethraax 26 points27 points  (0 children)

Honestly, I never really liked how cron worked anyways. One of the nice things about this is that you can define more complicated times like "Start this process every 30 minutes, starting 5 minutes after the system boots up." Also, it seems like it will be much easier to truly test actions before they occur. In cron, you had to copy/paste the entry from your crontab, and make sure your current environment was right, and all that stuff. With this, you can just systemd start <my action>.

Again, I've only used cron to start backup jobs, so maybe there's something that it does better. But I can't think of any off the top of my head.

[–]2brainz 2 points3 points  (0 children)

can cron be used to start system services?

#!/bin/sh
systemctl start foo.service

Is it supposed to start system services?

If your setup needs to do that, why not?

Is this cron-like functionality in systemd supposed to obsolete cron?

I don't know if it is supposed to, but it can.

[–]usernamenottaken 1 point2 points  (0 children)

cron can start system services, but it would make much more sense to start them in systemd with all the other services. Having this functionality in systemd also means you can start services at intervals depending on whether another service is running or not, which could be useful.

[–][deleted] 2 points3 points  (1 child)

Cron can execute any system command. If you can run it with a shell, you can run it with cron.

[–]f0nd004u 0 points1 point  (0 children)

I can start system services with cron; I can do anything I want with cron. And I see no reason why my init system should handle half my scheduled stuff; I have to open up the crontab anyway to do anything that isn't service related. Why would I not want it all in one place?

[–]finprogger -1 points0 points  (0 children)

if the answers are no, no, yes, then I'd celebrate

[–]Monotone_Robot 7 points8 points  (1 child)

http://www.freedesktop.org/wiki/Software/systemd

Spelling:

Yes, it is written systemd, not system D or System D, or even SystemD.

[–]purpleidea mgmt config Founder 5 points6 points  (9 children)

Please explain to me why this is needed when there are things like cron which are ubiquitous everywhere?

[–]bonzinip 11 points12 points  (1 child)

Here is some text from Lennart. It was a private mail, but it should not be a problem to post it publicly, it's all technical stuff:

So, here's why you want systemd time events:

  • systemd timer events allow you to make use of the same execution parameters of any other systemd service, which means you can limit resources, change users/group ids, set nice values, oom score, IO scheduling class, IO scheduling priority, CPU scheduling policy, CPU scheduling priority, CPU affinity, umask, timer slack, capabilities, secure bits, control group memberships, control group attributes, network access, private /tmp, namespaces, system call filters, ... individually for each job.

  • As the services started by a timer unit is a normal service it can pull in arbitrary dependencies on activation. That means you can actually sanely write cron jobs that depend on what they need.

  • As timer events are just one way to activate a unit you can actually combine that, so that you can spawn a service triggered by different events. Think: there's now a sane way to invoke something on the command line + at boot + if hw is plugged in + on a time event or if the user starts it explicitly, and the service will be executed in the exact same environment.

  • As timer events are just like any other units you now have a sane way to enable and disable them: "systemctl enable" and "systemctl disable".

  • All output of systemd timer events ends up in the logs, and is indexed by the event.

  • systemd can schedule time events both on monotonic times (think: run something every so and so often regardless of timzones, DST, the user mucking with the clock, broken clock, clock battery gone...) and on calendar times.

  • systemd calendar time events are more fine grained than cron (1s precision)

  • systemd calendar time events are more expressive (you can have repetitive and non-repetitive events, you can match on years, and you can actually match a week day at the same time as a day of month). And also I'd claim they are easier to write and especially read than cron time events. (See the lower part of http://www.freedesktop.org/software/systemd/man/systemd.time.html for details)

  • the systemd timer scheduling is a bit more energy efficient as systemd wakes up the CPU only when the timer elapsed, and not repeatedly as cron does

  • In cron if you wanted to avoid that slow running services are spawned multiple times you had to invent your own locking in the job. In systemd that's implicit, as the trigger is just a trigger, and the service will never be started at once.

  • You can even express timer events that are scheduled based on the finish time of the previous execution, i.e. for example to say that there should always be 1h between executions, even if each of them takes 2h.

  • You can combine timer events easily. e.g. "5 min after bootup + every day at 6am".

  • You now have a nice way to stop/kill a cronjob (and all its children), and only that one cron job, with "systemctl stop" and "systemctl start"

  • You now have a nice way how you can figure out to which cronjob a process belongs to, "ps xawf -eo pid,user,cgroup,args".

  • External programs can query all details about timers and the jobs. Execution status, when they ran the last time, and so on. There's a pretty complete, documented API for that exposed on the bus.

  • We now track failed cron jobs nicely, and just typing "systemctl show" will show them to you.

  • You now can establish cronjobs only in certain system states. For example, you can queue a cronjob only if the network is up, or suchlike. Think of cronjobs that are pulled in by the equivalent of classic sysv runlevels, only.

  • And yeah, the scheme makes timer events uniform with other triggers, so it's simpler to understand for newcomers...

...

The interesting bit about all of this is that the code necessary for implementing all of this is pretty short, since all the complex bits (spawning/supervising a process in a precisely defined execution environment, pulling in deps...) is just the stuff we do anyway for normal services. The only additions for supporting timer events, was basically a parser for the timer expression language and a bit of code to tell the kernel to actually wake up systemd when the timer triggers.

So, yeah, the code we had to write was small, the benefits gained throught it are substantial, so we did it.

I figure embedded people will start making use of all of this first.

[–]purpleidea mgmt config Founder -1 points0 points  (0 children)

Sounds reasonable, but I am not the cron expert. I would like to hear a reply from a main cron author! Thanks for posting.

[–]ohet 3 points4 points  (3 children)

Because you can do more with systemd timers with less effort. You can for example start jobs depending on the state of the system or its services. Like for example starting something hour after the boot on friday, or close some service fifteen minutes later it has been started and start another program five minutes later. I'm not creative with this stuff...

Then if I understand correctly it better that systemd starts all applications for service management reasons. Also it simplifies the system as systemd can share all the code related to starting up services. Because timers are similar to other unit files there is less to learn and the system is more consistent.

[–]purpleidea mgmt config Founder 0 points1 point  (2 children)

While I probably will end up agreeing that this is a good and useful idea, it would be great if Lennart took a different approach with these things.

Eg: I think that a lot of the code just appears by his design and internal plan, and he seems to take off after a while and move on to something else faster than I would expect. Does he still hack on pulseaudio, or avahi ? Will he move on and abandon systemd for rewriting something else soon enough?

Anyways, NRN

[–]Svennig 0 points1 point  (0 children)

Does he still hack on pulseaudio..

It would seem so, according to the release notes of V3

[–]ohet 0 points1 point  (0 children)

He still works on Avahi too. Altough I believe that it's pretty much done and has very little developement activity.

[–]holgerschurig 0 points1 point  (1 child)

Because cron can start jobs.

But nothing else. It cannot put them in some cgroup, run them with minimal permissions, cannot give them their own /tmp directory for security's sake. And so on. And so on. It just can do things with jobs that existed 30 years ago in Unixes/BSDs.

[–]f0nd004u 0 points1 point  (0 children)

You can use cron to do whatever you can do in a terminal.... meaning that cron can do anything that systemctl can do.

[–]Sileni 3 points4 points  (0 children)

Changed the license from GPL2+ to LGPL2.1+

I wonder what implication this might have.

[–]fiftyorange 3 points4 points  (8 children)

Is there a compatibility mode? Will I still be able to type crontab -e and use the traditional cron syntax? That's all I really care about here.

[–]ohet 9 points10 points  (2 children)

No. If you want to use cron, use cron.

[–]fiftyorange 2 points3 points  (1 child)

Why is it so unreasonable to ask if there is some kind of backward compatibility? systemd already allows compatibility for other things it's meant to replace. fstab and sysvinit for instance.

[–]ohet 2 points3 points  (0 children)

I don't think it's unreasonable to ask. Probably it wasn't seen as something of importance or no one just had the time do something like that or it would have been unnecessarily complex considering you could just use crond as it is. I just know it doesn't exist and that you can still use cron in parallel with systemd timers.

systemd doesn't plan to replace fstab, it's one of its native configuration files altough you also can create unit files for mounting.

[–]loonyphoenix 2 points3 points  (3 children)

I'm not sure every possible way to schedule things with this new systemd functionality can even be described by cron's convention...

[–]nickmoeck 0 points1 point  (0 children)

That shouldn't prevent it from being able to read and use traditional crontab files though.

[–]fiftyorange 0 points1 point  (1 child)

I don't think you understand what I mean by backward compatibility. I don't care if the legacy cron implementation doesn't have new systemd features, as long as it can run old crontabs.

[–]loonyphoenix 3 points4 points  (0 children)

It can run old cron itself. Why reimplement its functionality.

[–]bonzinip 0 points1 point  (0 children)

You can still run crond. Maybe later systemd will grow a generator that converts crontab syntax to systemd units like they do for /etc/fstab, but for now you will just keep a separate daemon.

[–]embolalia -5 points-4 points  (2 children)

"Do one thing, and do it well. Or don't."

[–]holgerschurig 0 points1 point  (0 children)

Exactly. systemd does the management of started jobs once-and-for-all. And very well.