Systemd Gets An Fsck Daemon/Service

[mark_]

Don't like systemd? install gentoo, build linux from scratch, don't like those options? then you shouldn't complain when companies that don't want to deal with hundreds of different parts and choose a base system.
and when your done good luck convincing app developers that they should build their stuff for your little particular corner of just the way you like linux.

I am using gentoo and regardless of that I can complain as much as I want

[Stellarwind]

Good.

Fsck is one of those things that need to be as robust as possible and since it usually has to be accessible early in boot ( if it is to be useful), its optimal place is within systemd.

Real reason for this change is likely this bug: https://bugzilla.redhat.com/show_bug.cgi?id=719952
You just can't cancel fsck during boot with systemd (by default, there are workarounds with their own issues), that is why they are making this tool. Canonical is just cleaning up the mess after "the god".
It works fine for sysv or upstart, but systemd couldn't fix this since 2011.

[edmon]

So it seems that soon out beloved Debian GNU/Linux will become Debian systemd/Linux?!?!! hehe
They even can go further and change it to Debian RH/Linux where RH is for RedHat :0

[nukem]

Did anyone actually read the commit message or better yet, look at the source? All this does is allow for a common interface of fsck programs to communicate with system whats going on. Is fsck running? Trying to fix something? How far done? etc. This is something which could be very useful for the init manager to know.

[Stellarwind]

systemd really is very modular; the whole intention is that people/distros can turn features on or off so that systemd can scale from tiny embedded devices to supercomputers and massive scale clusters

systemd likely won't work on tiny embedded devices, because they refuse to support something other than glibc.

[Skrapion]

Your complaint seems a bit off-target, given that GNU are the ones putting together dmd and Guix to offer a legit alternative standard base system. From what I've been reading, dmd and Guix are being developed quite rapidly.

As best I can tell, dmd and Guix are half-baked copies of Upstart and Nix. I don't see that they're really bringing anything new to the table here.

[Stellarwind]

Did anyone actually read the commit message or better yet, look at the source? All this does is allow for a common interface of fsck programs to communicate with system whats going on. Is fsck running? Trying to fix something? How far done? etc. This is something which could be very useful for the init manager to know.

systemd knows perfectly well if fsck is running, since it started it, why would init care how far it is done?
The real reason is that you can not cancel systemd-fsck with ctrl-c like with any normal init.

[Luke_Wolf]

I'd just like to interject for a moment. What you?re referring to as Linux, is in fact, systemd/Linux, or as I?ve recently taken to calling it, systemd plus Linux.

will you also accept lisystemdnux?

[przemoli]

systemd knows perfectly well if fsck is running, since it started it, why would init care how far it is done?
The real reason is that you can not cancel systemd-fsck with ctrl-c like with any normal init.

There is no such thing as FSCK

There is fsck for file system A, for file system B, for file system C, for.....
Each and every one of them can have different API/options/capabilities.

SysVInit have same problem here.

However in SysVinit everybody was happy about sloppy code each unique for each fsck implementation.

[renox]

As best I can tell, dmd and Guix are half-baked copies of Upstart and Nix. I don't see that they're really bringing anything new to the table here.

Guix brings to Nix the use of a general purpose language instead of a special language for configuration (which is almost always a bad idea), now when Guix will have matured should Nix stay?
In theory no, in practice fragmentation is the way of life in the Linux world..