Hacker News Reader

Comment by erik_seaberg | Hacker News Reader

I seem to recall this is incompatible with cronjobs, which puts it pretty far to the the game console end of the tool spectrum.

View on HN

Pretty sure it also breaks ssh logins. This needs more discussion before blessing it. Systemd has bled far, far, beyond an init replacement.

> Systemd has bled far, far, beyond an init replacement.

This has been my main objection to it: feature creep (with tight coupling between 'components').

Don't worry about SSH, just wait for the systemd replacement for SSH.

You can store SSH keys in the user records.

systemd was never just an init replacement, it's a project that includes an init replacement.

Systemd-homed isn't inventing the idea of encrypted home partitions and fundamentally, what you're saying is that cron is incompatible with encrypted home partitions (or any other auto mounted home partition, ex: network mounted). The same is true for the concerns about ssh.

If you listened to the original talk from Lennart, you're really just giving examples of one of his major points. Because /etc/passwd wasnt flexible enough to accomodate arbitrary user properties, user configuration has organically spread out over time into all these "side car" configuration files. Some are scattered around /etc so not easily portable while others are in the user's home directory and suffer from exactly the scenario you've mentioned. One of the goals of systemd-homed is to add a portable, extensible format for a user record external to the home directory which would mean that systemd-homed rather than causing, could actually lead to a solution for the issue you've highlighted.

I'm not sure if your comment is accurate or not, but systemd timers have existed for a while now, and provide some flexibility cron doesn't.

They had better provide flexibility for all the complexity and tedium they introduce. It takes creating two new config files of about 10 lines each and a long system command to set up the simplest possible systemd timer.

Yep, I wanted to create a systemd timer to run my nightly backups.

I was pretty shocked that I needed to have three files. My backup script, a systemd service to call the backup script, and a systemd timer to call my systemd service that calls my backup script.

It took A LOT of fiddling and reading the Arch wiki before I had everything working as I wanted it to.

I have also set up timers in Arch, and it wasn't that bad...

Really? How did you do it then?

https://wiki.archlinux.org/index.php/Systemd/Timers

You can also find more documentation on the official systemd website, or Gentoo, CoreOS, and RedHat's website.

As an example: https://wiki.gentoo.org/wiki/Systemd#Timer_services

I'm confused, unless I'm missing something, both of those pages seem to describe exactly the process mbreedlove described:

    1) create systemd service to call your script
    2) create a systemd timer to call that service

What did you do differently?

I didn't say I did anything different, I said it wasn't that difficult.

Please elaborate because that sounds odd to me. How on earth can a home directory manager mess with another daemon? I use winbind's associated PAM NSS module to run up a home dir as needed for my AD joined Linux machines. cron still works.

I don't do games consoles, only business systems.

Easy: crontabs are in /var/spool/cron/..., not /home, and user editable. If the user's homedir isn't mounted because they logged off and cleared their security tokens, any crontab they write that uses their homedir will break.

The same way pulseaudio stops playing when the screen locks. Most annyoing behaviour I've ever had.

That's a reasonable default behaviour, can you change it though?

Reply on news.ycombinator.com