Live data from Hacker News

Systemd.timer, an Alternative to Cron

andrewpillar.com

111–120 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#111

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…

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

I don’t think thats what’s happening here. Providing online documentation thats easy to read, easy to navigate has become quite standard of all kinda of projects and systems. My main programming environment is a mac so Im certainly not gonna have the locally installed docs anyway.

Not only does a good online documentation make it easier to understand for an individual, but it makes it easy to share links etc to others to help them understand too. And the easier it is to comprehend, the better.

Re: Systemd.timer, an Alternative to Cron

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

Re: Systemd.timer, an Alternative to Cron

#113

Earlier quoted context omitted.

Binary log files is another example of something that could have advantages in theory but never seems to work well in practice. What used to be "tail /var/log/nginx.log" is now man journalctl journalctl -u nginx journalctl | grep nginx go back to man page to look for more options to search etc

"tail /var/log/nginx.log" is now "journalctl -fu nginx" or "jouranlctl -eu nginx". Not that much of a difference, it really depends what you grow up with. We could argue "tail" is ugly because you never know if it's "tail /var/log/nginx.log" or "tail /var/log/nginx/nginx.log". A nice feature is that journald gives you flags like "--boot" to see logs only emitted during a specific boot, or "--since '5m ago'" which is…

> Not that much of a difference

It's a big difference, not because one command, but because tail is part of the standard unix toolset that works with all files. Except now you have this one log file that is special and needs a different unique tool.

Re: Systemd.timer, an Alternative to Cron

#114

Earlier quoted context omitted.

No, having a special way to tail your special log file isn't a feature, tail is a general utility used system wide for this for decades; breaking this is idiotic no matter what you grew up with.

I'm happy we have special-purpose tools for dealing with logfiles. I don't want to craft one-liners for "give me logs around timestamp" or "give me logs about my service's first start after the boot" every other day.

"I don't want to craft one-liners"

I do. I specifically want that as a more valuable and powerful feature. Undifferentiated, open-ended, general purpose, sharp tools are infinitely more useful.

Re: Systemd.timer, an Alternative to Cron

#115
post #111

Earlier quoted context omitted.

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

> It's such a weird disconnect seeing people that can't go outside of the mindset that everything is a web application. I don’t think thats what’s happening here. Providing online documentation thats easy to read, easy to navigate has become quite standard of all kinda of projects and systems. My main programming environment is a mac so Im certainly not gonna have the locally installed docs anyway. Not only does a go…

iOS is not a target for systemd, and the building blocks of a *nix system probably are not the building blocks of iOS.

> Not only does a good online documentation make it easier to understand for an individual, but it makes it easy to share links etc to others to help them understand too

God forbid developers package their software considering the needs of users that don't have 24/7 internet access. If it wasn't clear from my previous statement, this is what I wanted to express by the "mindset that everything is a web-application".

Re: Systemd.timer, an Alternative to Cron

#116

Earlier quoted context omitted.

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

> still no How To.

How to what? systemd umbrella contains a lot of functionality, just like the detractors keep on telling us.

If you found a way to improve the systemd documentation you should probably reach out to the devs: https://github.com/systemd/systemd/tree/main/docs

Re: Systemd.timer, an Alternative to Cron

#117

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 seemed to never care until they took my sysvinit away (or maybe any decent init system :D). Then they took resolv.conf control away. Then when I shutdown my computer, some random process takes 1 min 30 seconds to shutdown when it probably doesn't need to. Then I read on hacker news recently that Fedora uses a systemd daemon for handling OOM and the writer said it was terribly misconfigured particularly when it shut…

'Terribly misconfigured' sounds like a bug report should be filed at the distro level, not a complaint about the upstream tool on HN ;-)

Re: Systemd.timer, an Alternative to Cron

#118

Earlier quoted context omitted.

I seemed to never care until they took my sysvinit away (or maybe any decent init system :D). Then they took resolv.conf control away. Then when I shutdown my computer, some random process takes 1 min 30 seconds to shutdown when it probably doesn't need to. Then I read on hacker news recently that Fedora uses a systemd daemon for handling OOM and the writer said it was terribly misconfigured particularly when it shut…

'Terribly misconfigured' sounds like a bug report should be filed at the distro level, not a complaint about the upstream tool on HN ;-)

Hopefully the author did that :) https://news.ycombinator.com/item?id=33894469

Re: Systemd.timer, an Alternative to Cron

#119
post #36

Earlier quoted context omitted.

"tail /var/log/nginx.log" is now "journalctl -fu nginx" or "jouranlctl -eu nginx". Not that much of a difference, it really depends what you grow up with. We could argue "tail" is ugly because you never know if it's "tail /var/log/nginx.log" or "tail /var/log/nginx/nginx.log". A nice feature is that journald gives you flags like "--boot" to see logs only emitted during a specific boot, or "--since '5m ago'" which is…

> We could argue "tail" is ugly because you never know if it's "tail /var/log/nginx.log" or "tail /var/log/nginx/nginx.log". The difference is that you can use ls to find out, the same ls that you use when working with everything else, rather than needing to know some journald-specific thing that will only ever work for journald and will no doubt change again in another 5 years.

And you can just issue “systemctl” to list every service. Do you blame excavation machines because you can’t drive them when you only know how to drive a car?

Re: Systemd.timer, an Alternative to Cron

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

Socket activation is declarative. My last point is the dynamic one, but that is just calling out to systemd. The point is, all three can share the same service description.
Post reply on HN