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

141–150 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#141

Post by egberts1 »

kaba0 wrote: post #121
egberts1 wrote: post #98

Earlier quoted context omitted.

Failsafe? I'm still experiencing file corruption regularly with journald on various distros. Cannot recall corruption nor unreadability with syslog.

Then you have some corrupted hardware. Also, syslog wasn’t capable of logging during the initial stages of boot, which is pretty important.

Then there aught to be some kind of fsck (file checking) for journal files.

To forever complain until user intervention is downright silly.

Five separate but disparate hardware does not make for a probable hardware error.

Re: Systemd.timer, an Alternative to Cron

#142

Post by kzrdude »

phpisthebest wrote: post #93
kzrdude wrote: post #75

Earlier quoted context omitted.

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…

In general convention doesn't work so well if you're not really into the system. I.e the casual users.

Convention means that behaviour depends on not just what's present but also what's not present. So it is of course missing some of the explicitness. For the directories, you need to understand which directories to look into and in which order they are taken into account (for systemd this is hard enough that's it's best to be tool assisted).

Re: Systemd.timer, an Alternative to Cron

#143

Post by marbu »

ilyt wrote: post #132
marbu wrote: post #127

Earlier quoted context omitted.

I don't have a negative experience with journald file format. That said, the format is documented here: https://systemd.io/JOURNAL_FILE_FORMAT/ On the other hand I agree that journald seems to call open syscall more often than I would originally expect, which can be a problem for some edge cases[1], but I don't consider this to be a real problem. [1] https://blog.marbu.eu/posts/2022-11-20-ebpf-journald/

The problem is: If cache is hot, you have hundreds of MBs of systemd logs littering your buffer cache, while it could be used for something more useful If cache is cold simple operations like systemctl status take up to tens of seconds, especially on loaded servers. Example: # time systemctl status influxdb >/dev/null real 0m11.913s user 0m0.013s sys 0m0.531s It doesn't even keep index of "last file where app wrote l…

But this buffer cache usage is caused by readers/clients checking logs for some reason, not logging itself, right? I see no significant difference compared to syslog here: if I grep all logs for something, it will also place these logs into buffer cache.

Your example with dropping cache and running systemctl status is indeed interesting, 11s looks like too much. But it's a number without a context, and I wonder how big a problem this actually is. I haven't noticed it myself before.

> It doesn't even keep index of "last file where app wrote logs" which causes above.

While I definitely see some room for optimization, I'm not sure what you mean here: journald uses one active journald database file, there should not be a problem with figuring out where the file is, should it?

Re: Systemd.timer, an Alternative to Cron

#145

Post by yawaramin »

exabrial wrote: post #112

> Job output will automatically be written to systemd-journald This is a bad thing, not something I’d boast about. I actually really enjoy using systemd. Being able to start a process with complete isolation without heavyweight docker downloading mystery meat off the internet is a huge boon. However, one thing systemd is logging. Jounalctl sucks. Grep, cat, etc, work infinitesimally better.

'Infinitesimally' means 'by a negligible amount'. Which is (accidentally) accurate. There's nothing preventing you from using grep, cat, etc. with the output of journalctl. It's just a tool in the pipeline.

Re: Systemd.timer, an Alternative to Cron

#146

Post by yawaramin »

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.

Because a service may not always be triggered by a timer. Sometimes it could be triggered manually. Sometimes by a volume being mounted or unmounted. Sometimes by a request from a socket. By decoupling them they become reusable components. Actually, much like Unix tools which people love going on about.

Re: Systemd.timer, an Alternative to Cron

#147

Post by yawaramin »

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?

Yes, a for-profit corporation has the nefarious plan to... checks notes ...try to earn more revenues. We certainly can't stand for that!

Re: Systemd.timer, an Alternative to Cron

#148

Post by sliken »

yawaramin wrote: post #147
sliken wrote: post #10

Earlier quoted context omitted.

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

Yes, a for-profit corporation has the nefarious plan to... checks notes ...try to earn more revenues. We certainly can't stand for that!

Heh, well making your product worse for more revenue seems pretty warped, and increases the risk of lost market share. Even more warped is having 2 of your engineers join the Debian technical committee and use the bylaws to force a vote before anyone figures out exactly what SystemD is.

Re: Systemd.timer, an Alternative to Cron

#149

Post by [deleted] »

sliken wrote: post #148
yawaramin wrote: post #147

Earlier quoted context omitted.

Yes, a for-profit corporation has the nefarious plan to... checks notes ...try to earn more revenues. We certainly can't stand for that!

Heh, well making your product worse for more revenue seems pretty warped, and increases the risk of lost market share. Even more warped is having 2 of your engineers join the Debian technical committee and use the bylaws to force a vote before anyone figures out exactly what SystemD is.

[deleted]

Re: Systemd.timer, an Alternative to Cron

#150

Post by tb_technical »

yawaramin wrote: post #144
tb_technical wrote: post #94

Why? Crob is simple, well understood, and works well. Why in god's name do you want to reinvent the wheel?

How does it work if I want to ensure that a certain volume must be mounted before a job runs?

Add the check at the start of the script?
Post reply on HN