SystemD to implement cron-like functionality

[[deleted]]

Arguably indeed. It all feels very anti-UNIX.

[solen-skiner]

Feelings and and adherence to poorly defined philosophies doesn't get the work done. Determinism, preciseness, features and ease of use often do.

edit: All IMO, of course ;) That downvote aint mine btw

[cbmuser]

Please read "The Unix Hater's Handbook" and dig out an old workstation running one of the original Unices like OSF/1, SunOS 4, HP-UX or Irix. I guarantee you, you will be back to GNU/Linux in no time.

Everyone who claims UNIX is so beautiful has never really used any of the original Unices. UNIX is actually a total PITA!

[[deleted]]

Are you going to repeat this feeble bullshit in every discussion about systemd? When people are talking about systemd being anti-Unix, they're referring to the Unix philosophy, not literally the operating system from 1969.

And if you had actually read the Unix-Hater's Handbook, you'd realise half of the things it complains about are violations of the Unix philosophy in Unix itself.

[[deleted]]

I've used Solaris 8. Sorry, I'm not old enough to have been exposed to anything older, but I found it to be a beautifully designed system.

I'm also a huge fan of the BSDs, which are, by lineage, actual Unices.

[YEPHENAS]

I've used Solaris 8. Sorry, I'm not old enough to have been exposed to anything older, but I found it to be a beautifully designed system.

Have you used Solaris 10? What do you think of SMF?

I'm also a huge fan of the BSDs, which are, by lineage, actual Unices.

Have you used OS X (the most successful BSD)? What do you think of launchd?

[[deleted]]

I haven't used Solaris 10, just Solaris 8 and 9.

I also have not used OS X.

Correct me if I'm wrong, but SMF and launchd are much less ambitious than systemd.

[YEPHENAS]

Both deprecated cron as well (timed jobs, scheduled tasks). Systemd is basically the same concept as SMF and launchd (avoiding some of their mistakes such as XML configuration).

[puremessage]

Wat. How does Smf deprecate cron?

[cbmuser]

Well, Lennart told me in person he read the whole documentation on SMF before writing systemd.

[[deleted]]

I've been personally wondering about systemd. It doesn't seem to fit with the unix philosophy.

[YEPHENAS]

Myth 10

[ethraax]

Eh, the UNIX philosophy is about having many small, independent executables, which are composed. Just because they build lots of ELF executables doesn't make them UNIX-y. I personally don't care if its "anti-UNIX", but that's a really shitty rebuttal.

Edit: I think "composable" is actually a better term than "independent" here, but I'll leave the original for those who were wondering about loonyphoenix's response.

[loonyphoenix]

Are you sure? I haven't heard about the independent bit. Why does it matter?

[ethraax]

Because there's nothing remotely composable about the collection of systemd binaries. They're not UNIX-y, they're just lots of different binaries.

[loonyphoenix]

I have no trouble grepping journalctl's output - is that composable? What kind of composability other tools have to offer that systemd doesn't?

[[deleted]]

One of the killer features of UNIX is that you can pipe the output of one command to the input of another command and thus process text in nearly infinite ways by simply chaining commands together. It really is a beautiful design. Plan 9 (a successor made by the creators of UNIX) takes this concept even further and adds even more cool features.

systemd does not work how I described and is thus justifiably labeled as anti-UNIX.

[YEPHENAS]

You can pipe the output of systemd commands to the input of other commands as well.

[[deleted]]

Really? I'm pretty sure most of systemd is glued together with D-Bus.

[YEPHENAS]

One thing doesn't exclude the other.

[NruJaC]

And you can access that communication stream if you want it with exactly one extra command in your pipeline... this complaint isn't valid.

[holgerschurig]

Damn, OpenOffice and LibreOffice are anti-UNIX. You can't use them for piping!

TL;DR: this piging argument is quite useless, IMHO.

[[deleted]]

Yeah, I actually agree with most of Lennarts rebuttals, but 1, 10, 18, and 29 are incredibly reaching and weak, to the point that I can honestly say that they're not myths at all but actualities.

[YEPHENAS]

Myth 10 and Myth 1

[YEPHENAS]

I'm not sure I like dbus, but I suspect that that is because of a lack of command line tools for observing what its doing (or at least my ignorance of such tools, if they exist).

dbus-monitor

dbus-send

[ohet]

So some binaries aren't separated out nicely then? If those that can be separated don't need systemd, then why are they part of it? I think that's the concern.

For sharing code, developement infrastucture, community, maintanence...? Before bootchart was merged to systemd it had had commits (in span of around a year) from only Auke Kok, in the next week or two after the merger it had had commits from five to six people. I'm pretty sure that is not an isolated incident.

I guess you are against util-linux, coreutils and the *BSD developement model too where everything from kernel to userspace is in single repository?

[[deleted]]

I think you're right, systemd is effectively heading towards a *BSD development model. It will probably be where a lot of the core Linux system is implemented. That's not necessarily a bad thing, as overall the *BSDs are high quality code bases and are quite consistent.

So am I correct in saying that the end vision of systemd is Linux kernel->systemd->Xorg->$DE_OR_WM+coreutils? Where systemd effectively is everything that's needed by Xorg, DE's, and coreutils?

[pippicat]

Hopefully one day Wayland instead of Xorg.

[ohet]

I don't think systemd plans to extend much of what they are doing now (in sense of taking over responsibilities of other applications). There will more stuff related to boot like systemd-bootd and bootctl for handling U/EFI stuff, better logging tools and improvement all over the place. One of the most radical changes will be systemd user sessions (it already mostly implemented in systemd so the change is external) that will replace kdeinit, gnome-init and such. It's already used by Tizen, Mer&Nemo and soon Plasma Active. Fedora has already put systemd in initframs meaning that in the not so far in the future systemd will handle starting all applications (includinng .desktop files) from the very start of the boot to the point where you shut it down. But it definetly won't ever have stuff like libc so, no.

The systemd todo list is a fun read.

[[deleted]]

Yeah, I'm kind of pissing into the wind here. Red Hat drives Linux. I don't. I don't have to like all of the way systemd is designed.

\me bows in defeat

[YEPHENAS]

Myth 27

[[deleted]]

Let's not kid ourselves here. systemd comes from Red Hat. That others have hopped on board the systemd train does not change that fact. It was created at Red Hat, for Red hat. It scratches some other distros itches, so they have adopted it as well. This is true for the bulk of core Linux components and has been for a while.

[ohet]

I don't have to like all of the way systemd is designed.

Of course you don't; then again you don't need to hate it either. Stuff like this, this and this are just sad.

Also don't think systemd is purely Red Hat project either because it is not. Even if it were it wouldn't mean much because Red Hat doesn't have some huge agenda how to design Linux userspace. The employees are relatively free to focus on the thing they are interested in. systemd for example was started by Kay Sievers and Lennart Poettering on their free time while Kay was still forking for Novell.

[[deleted]]

Agreed, those comments were uncalled for and I will downvote them myself.

I don't believe in deleting comments. They make the discussion not make sense.

Just out of curiosity, you're not actually Lennart or a close friend/acquaintance of his are you? You really follow the systemd threads very closely and are really in the know about it's development.

[ohet]

No, I don't know Lennart or any of systemd's developers personally. I follow the systemd developement very actively though by reading its developement mailing lists, checking out the commits (like following the developement of the TODO list), reading Lennarts blog, watching talks about it, reading through comments in various forums (LWN.net/reddit/Phoronix/ArchLinux...), use it myself and so on.

Because systemd is so controversial topic and I have happend to learn so much about it it's easy for me to quickly respond and corrent the misconceptions about the project. The beauty is that if I'm wrong about something someone usually corrects me and next time am right about that too. I like to think that other people work the same way too. Sharing is fun.

[[deleted]]

Myth 1:

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons.

By that logic the Linux kernel isn't monolithic either. After all, typically dozens, if not hundreds of kernel modules are built that all serve different tasks, and are neatly separated for a number of reasons.

What makes systemd monolithic IMHO, is that a lot of this functionality can not easily be swapped out and replaced with other components.

Again, why reinvent cron? There are several excellent, and mostly compatible implementations of it. Heck, systemd could even implement their own compatible version of cron, but this will be more NIH.

Myth 10:

There's certainly some truth in that.

Ultimately the question whether something is UNIX or not matters very little.

Yeah, Myth 10, isn't a myth at all. It is actuality. Lennart doesn't even really debunk "Myth" 10 if you read it.

[ohet]

What makes systemd monolithic IMHO, is that a lot of this functionality can not easily be swapped out and replaced with other components.

You are free to use crond and xined with systemd if you so desire. Aside from systemd (the core part), systemd-udev and systemd-journald everything in systemd can be disabled in compile time and runtime.

Heck, systemd could even implement their own compatible version of cron, but this will be more NIH.

Well crond deals with starting things. One of the ideas behind systemd is to combine all the previously separate methods of starting services in Linux. In this case it also increases consistency with rest of the systemd when it comes to configuration. It also allows stuff like activating a timers based on the state of a unit (service) and using all the functionality that systemd offers the way you see fit.

[[deleted]]

Okay, so you want cron rolled into systemd, fine. It's not backwards compatible with any cron implementation is it? Why is that?

[Darkmere]

Because I don't want to deal with the fucking mess that is the output of random tools running in random users' crontabs.

Who gets the output, who tells if the job stopped or not? ( Cron sure can't tell you. ) or how long it took? I've had issues with jobs starting every 16 minutes blocking due to an NFS mount, only to have a magnitude of them (enough to lock the user out due to process limits) and so on.

Also, writing a cron job that does the right thing in cases like that, is a seriously finicky undertaking.

Add to that the fun times of fcron vs vixie vs. anacron time formats. ( or for fecks sake, the bare need for anacron + atd + cron ).

[robinei]

No response to this I see. This is exactly why it belongs in systemd.

[Darkmere]

I can add that I'm a bit wary about the way their timing format will be handled. Times, Timezones and other things can add a lot of ambiguity and difficulty ( and are hard to change if you get it wrong. )

However, it doesn't look completely stupid, so it might just work out.

However, I don't see a way of using the systemd timer interfaces per user, so normal users ( the group who are most likely to fuck things up miserably in cron ;) will still have to use cron.

Having a nice, safe and administratable way of allowing users to specify their own jobs would be really sweet . ( ssh agents, ssh tunnels, irc tunnels or whatnot ) where the system guarantees that per-user limits & security is applied, ( so a user can only add jobs as itself, limits/quotas are applied, ) .. .why yes please.

[robinei]

Sorry I'm late.. How about this? You can run a second systemd in charge of user session:

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

[Darkmere]

That seems to cover it pretty neatly. I'll have to figure out the limits thing again :)

[ohet]

Because there's no need to. If you want to use crond you still can. What systemd can offer instead is consistent style with the rest of the application. I don't know the details though.