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

91–100 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#91

Post by dale_glass »

jeroenhd wrote: post #86
smm11 wrote: post #44

Quoted post unavailable.

God, I wish Linux would copy more Windows features. Service management before systemd was a hell of intermingled shell scripts (that often specified sh but only ran on bash) and side effects everywhere. Cron is a very stable tool but it should've been replaced when the first GUI ran on Linux. I don't understand this idolisation of 70s mainframes that "hardcore" Linux users all seem to fight for. Systemd features can…

Yup, I'm honestly confused about the weird strain of conservatism in some Linux circles.

I've been an user of Linux since quite early on. Back then I recall a lot of enthusiasm for the desktop and attempts to make the user's life easier. Things like YAST were a selling point, there was the framebuffer console for a prettier boot, and Enlightenment if you wanted all the gratuitous eye candy your CPU could handle. There seemed a lot of interest in making things better and look cooler. It was a world full of possibilities, back when the Windows users rarely got more than changing the UI font to something weird.

Today there's this weird attachment not only to the days before that, but to the things that sucked. Like there's some people that are nostalgic for FTP for some reason I can't quite understand. FTP is an awful protocol, and which resulted in countless corrupted packages transferred in ASCII mode.

Re: Systemd.timer, an Alternative to Cron

#92

Post by traverseda »

outworlder wrote: post #85
traverseda wrote: post #3

https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a…

I guess preferences will mostly depend on how the system is being used. If this is your desktop machine sure, do crontab -e and add a line. If it is a system sitting in a colo or cloud provider, it's likely that it's been configured through automation anyways so "locality" doesn't matter. Your scripts know where stuff is located.

My scripts an also do things like assemble a crontab, since it doesn't matter.

Re: Systemd.timer, an Alternative to Cron

#93

Post by phpisthebest »

kzrdude wrote: post #75
phpisthebest wrote: post #11

Earlier quoted context omitted.

>>Locality of behavior is important. Even your own link talks about the Subjectivity of that opinion, and how LoB is often in conflict with DRY and SoC, both of which I support far more than LoB. In this context systemd favors Separation of Concerns, the the service is what is being run, and the timer is when is it being run... it is not that the devs do not "seem to understand why locality of behavior would be desir…

Why isn't the timer stuff just an optional [Timer] in a unit file? Then it would be separate (separate section), even if it's in the same file.

that would be a convention or configuration debate

I prefer convention for systemd. The justification for have a separate timer file instead it being in the unit file would be making it easier for someone to quickly look at what services are running on timers vs running by targets.

if timers where in the services file you would have to open each one to find out what had a timer, with a separate file you just look at which service as a timer provided your naming is standardized)

Re: Systemd.timer, an Alternative to Cron

#95

Post by phpisthebest »

traverseda wrote: post #16
phpisthebest wrote: post #11

Earlier quoted context omitted.

>>Locality of behavior is important. Even your own link talks about the Subjectivity of that opinion, and how LoB is often in conflict with DRY and SoC, both of which I support far more than LoB. In this context systemd favors Separation of Concerns, the the service is what is being run, and the timer is when is it being run... it is not that the devs do not "seem to understand why locality of behavior would be desir…

I think that's probably a trade off that large enterprises often make. It tends to work well for very large teams, and especially if you're trying to make your tech team fungible. Still, there's such a thing as taking it too far. I think there's a middle ground. Sure, a single crontab makes it hard for packages to schedule things and makes it hard to assign ownership to individual packages/people/whatever. I can reco…

>>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 WONDERFUL and absolutely needed change to the world of linux administration.

cron was written in a time where verbosity had actual costs to the system, we are not in those times and the need for nostalgia to be cryptic and only use minimum chars is over and I for one am glad for it.

Both in programming and administration people need to be MORE VERBOSE not less

Re: Systemd.timer, an Alternative to Cron

#96

Post by traverseda »

phpisthebest wrote: post #95
traverseda wrote: post #16

Earlier quoted context omitted.

I think that's probably a trade off that large enterprises often make. It tends to work well for very large teams, and especially if you're trying to make your tech team fungible. Still, there's such a thing as taking it too far. I think there's a middle ground. Sure, a single crontab makes it hard for packages to schedule things and makes it hard to assign ownership to individual packages/people/whatever. I can reco…

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

Re: Systemd.timer, an Alternative to Cron

#97

Post by egberts1 »

sliken wrote: post #10
traverseda wrote: post #6

Earlier quoted context omitted.

One of my earliest experiences with systemd's binary log files was on an embedded system I had ~~chrooted~~ systemd-nspawned into, and every time I tried to get the log output it would segfault (some issue with qemu-static probably). Very frustrating experience. Really feels like "Embrace, extend, extinguish" but the thing they're extinguishing is unix-as-a-programming-environemnt.

Or a Redhat plan to generate more consulting/support income. Ever wonder why Oracle products were so hard to install/maintain?

It's the IBM way.

Everything be in 4-digit or 5-digit error code.

Need to RTFM for such codes. Or worse, StackOverflow them.

Re: Systemd.timer, an Alternative to Cron

#98

Post by egberts1 »

cookiengineer wrote: post #80
traverseda wrote: post #3

https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a…

Counter argument: Try implementing support for Alpine, Debian and other distros whilst using a cronjob. It's impossible. All that opinionated /etc/crontab and /etc/cron.daily shit can go to hell for all I care. Every opinionated distro uses whatever kind of file format that the next best sh guru came up with, which id also prone for exploitation btw. With systemd there's a failsafe way for maintainers to offer a cros…

Failsafe?

I'm still experiencing file corruption regularly with journald on various distros.

Cannot recall corruption nor unreadability with syslog.

Re: Systemd.timer, an Alternative to Cron

#99

Post by bravetraveler »

traverseda wrote: post #60
kaba0 wrote: post #31

Earlier quoted context omitted.

Starting a service is way different than the service itself, what if I want it to be started when a request hits a given port? Also, the service files themselves are usually packaged up and are immutable, and every user will want different behavior on when it is started. To me it sounds like proper architecture and your solution would be needless close coupling.

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

Re: Systemd.timer, an Alternative to Cron

#100

Post by egberts1 »

dinosaurdynasty wrote: post #48
pm90 wrote: post #13

I've had the opportunity to delve into systemd in a previous role. This sounds a bit weird, but its not easy to get started with, unless you're used to reading man pages. But once you're able to read man pages, all of systemd behavior is documented in the man pages. I do wish there were more human friendly docs though, especially for younger engineers used to better sorts of docs. Anyways, once you do get the hang of…

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://egbert.net/blog/articles/debugging-a-service-in-syst...

Post reply on HN