Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd.timer, an Alternative to Cron

andrewpillar.com

Post reply on HN
Print view View original

101–110 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#101

Post by phpisthebest »

traverseda wrote: post #96
phpisthebest wrote: post #95

Earlier quoted context omitted.

>>Sure, a single crontab makes it hard for packages to schedule things and makes it hard to assign ownership to individual packages/people/whatever. and makes is hard for admins to schedule things, and make is hard to figure out what is scheduled when, and makes it hard to test if the process will work under the schedule. I absolutely hate cron's format, and pretty much everything else about it. systemd timers is a W…

Well I'm not complaining about systemd's verbosity here, I generally agree on that point. Nor am I saying cron is particularly good, I think there's definitely room for improvement. What I am saying is that splitting a basic timer between two different files is really bad for readability and understandability.

You are not splitting a timer between 2 files

you are splitting a service and a timer, not all services need a timer. I think that is point being glossed over

services may be called by a target, a timer, or manually. or all 3 when the need arises.

So for example if I have a process that I need to run on startup, every Friday, and sometimes adhoc I can create a single service file and do all 3, and know it is executed in the same way every time

could not do that with cron or even older init systems

Re: Systemd.timer, an Alternative to Cron

#102

Post by rektide »

traverseda wrote: post #62
rektide wrote: post #22

Earlier quoted context omitted.

'Make everything simple as it can be but no simpler'. To me your ask violates this. Timers augment the variety of existing service types, so your idea just doesnt work straight up, unless we severely limit the flexibility of what timers can be via the 'periodic' type. Or we make 'periodic-oneshot' 'periodic-serice' et cetera, which feels absurd. Perhaps we could leave Service= alone & just shoehorn each systemd.timer…

>We also cant just disable a timer temporarily Sure you can, comment that line out of the service file. It is ultimately just a text file that you can edit.

Again, inventing arbitrary hacks totally on your own that none of the builtin tools will know about or help you do. This seems obviously worse than having a seperate services actuated by separate timers.

Re: Systemd.timer, an Alternative to Cron

#103

Post by phpisthebest »

sparker72678 wrote: post #7

You can pry my crontab out of my cold, dead hands. Seriously, though, cron has been so utterly reliable for me for so many decades now, it will be really hard for me to ever give it up.

"I have always done it that way" is the absolute worst justification for anything.

Tradition: Just because you've always done it that way doesn't mean it's not incredibly stupid. -- Despair, inc

Every dev and administrator, or office user should have that poster above their desks

Re: Systemd.timer, an Alternative to Cron

#105

Post by traverseda »

bravetraveler wrote: post #99
traverseda wrote: post #60

Earlier quoted context omitted.

Sure, then let me put a command in my files instead of requiring a separate service. >what if I want it to be started when a request hits a given port? I really don't think you should be turning your init system into a general programming environment that can do that.

> I really don't think you should be turning your init system into a general programming environment that can do that. We have :) https://www.freedesktop.org/software/systemd/man/systemd.soc... No need for multiple anything, the units can be parameterized -- user@my.service , for example

Oh I know it's possible, I just don't think you should be doing that in an init system.

Re: Systemd.timer, an Alternative to Cron

#106

Post by mariusor »

egberts1 wrote: post #100
dinosaurdynasty wrote: post #48

Earlier quoted context omitted.

systemd has amazing documentation, you just have to read them...

I think a link prominently placed on their website would be helpful. Also systemd documentation isn't compliance with: * Tutorial * Explaination * How To * Reference For instance, I want to know which part of systemd uses `SYSTEMD_DEBUG`. Hold on ... I am digging thru the Git repo. Screw the systemd manual: Here's my environment variable reference guide for debugging systemd (that is NOT documented by systemd) https:…

> I think a link prominently placed on their website would be helpful.

It's such a weird disconnect seeing people that can't go outside of the mindset that everything is a web application.

Systemd ships their documentation (most of what you asked for, actually) with the package, and their environment variables description can be found in /usr/share/doc/systemd/ENVIRONMENT.md (at least on my machine).

When you're dealing with the applications which form the building blocks of a *nix environment your first step should not be google, but grepping through the /usr/share/doc, and using the apropos and man commands.

Re: Systemd.timer, an Alternative to Cron

#107

Post by bravetraveler »

traverseda wrote: post #105
bravetraveler wrote: post #99

Earlier quoted context omitted.

> I really don't think you should be turning your init system into a general programming environment that can do that. We have :) https://www.freedesktop.org/software/systemd/man/systemd.soc... No need for multiple anything, the units can be parameterized -- user@my.service , for example

Oh I know it's possible, I just don't think you should be doing that in an init system.

Understood, fair enough. I'm not too bothered by it, it's been useful here and there

Re: Systemd.timer, an Alternative to Cron

#108

Post by egberts1 »

mariusor wrote: post #106
egberts1 wrote: post #100

Earlier quoted context omitted.

I think a link prominently placed on their website would be helpful. Also systemd documentation isn't compliance with: * Tutorial * Explaination * How To * Reference For instance, I want to know which part of systemd uses `SYSTEMD_DEBUG`. Hold on ... I am digging thru the Git repo. Screw the systemd manual: Here's my environment variable reference guide for debugging systemd (that is NOT documented by systemd) https:…

> I think a link prominently placed on their website would be helpful. It's such a weird disconnect seeing people that can't go outside of the mindset that everything is a web application. Systemd ships their documentation (most of what you asked for, actually) with the package, and their environment variables description can be found in /usr/share/doc/systemd/ENVIRONMENT.md (at least on my machine). When you're deal…

Right. But still, I had to do some digging and this time it only came from its source code for description, references, and still no How To.

Re: Systemd.timer, an Alternative to Cron

#109

Post by __turbobrew__ »

Someone wrote: post #59
ilyt wrote: post #32

Earlier quoted context omitted.

Then again original cron is also kinda shit. It gets the "one file to define the job" right but that's the only thing that it gets right. There is no holistic view on the jobs so you can't easily say "show me last jobs that failed" and shove that into alert. There is email on failure but only on failure so you can't also do simple "if this mail returns fail, mark check as failed, if it returns okay, mark it as okay".…

> Systemd's timers should just be [Timer] block inside the .service systemd was inspired by launchd ( http://0pointer.de/blog/projects/systemd.html ), and that does that ( https://developer.apple.com/library/archive/documentation/Ma... ), so they must have explicitly made that choice.

The wrong choice in my opinion

Re: Systemd.timer, an Alternative to Cron

#110

Post by sparker72678 »

phpisthebest wrote: post #103
sparker72678 wrote: post #7

You can pry my crontab out of my cold, dead hands. Seriously, though, cron has been so utterly reliable for me for so many decades now, it will be really hard for me to ever give it up.

"I have always done it that way" is the absolute worst justification for anything. Tradition: Just because you've always done it that way doesn't mean it's not incredibly stupid. -- Despair, inc Every dev and administrator, or office user should have that poster above their desks

Maybe ask why the fence is there before you try to rip it down.
Post reply on HN