Uselessd
uselessd.darknedgy.net
uselessd.darknedgy.net
I really hope this takes off.
And you're worried about somebody calling their own project "uselessd"?
No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG.
The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd developers on handling this? Ignore it.
To be honest, if the format is done well there is no reason you cannot still read all the non corrupted records. textfiles corrupt too, you just generally live with them being broken because you can read the unbroken stuff.
Going by the bug tracker the journald approach is to make the reader work with broken files better.
The ridiculous "oh my god my logs will be always ruined thing" is a beat up by those who need to assassinate something about systemd, because it's always been devoid of any technical accuracy or discussion.
Things which have caused editors to hang or crash: 1. Binary data outside of the US-ASCII visible range 2. Malformed or creative Unicode combinations 3. Very long lines 4. Very many lines 5. Inconsistent line termination 6. Lines with patterns which trigger syntax highlighting, URL underlining, etc. 7. Embedded terminal escape sequences
It's not unreasonable to imagine that the journald developers might spend the same amount of time on safeguards, something which is easier with a well-defined binary format.
"I get shot going to work every day. But I bought a bullet proof vest, so life is okay."
Iron bandages don't solve problems, they for a short time work around them. Except because nobody actually like writing systems level code, they stick- forever.
You get corruption if the machine shuts down incorrectly. In binary or text files. In that case journald/syslogd act like a black box. Syslogd will give you whatever garbage it has in those text files, journald will give you the surviving records and will tell you which ones are unreadable.
If you want to not get shot, shut down your machine properly. If you cannot shut down your machine properly because it crashed then you have data garbage if you want it or not. Drives work that way.
I'm not sure what you are arguing for.
Journald does not write broken records itself.
Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.
ForwardToSyslog=yes in /etc/systemd/journald.conf.
That's a pretty good feature if you ask me.
systemd has libqrencode integration, in order to, if I recall correctly, display a QR code when you generate FSS keys from journalctl.
The documentation reminds me a lot of Emacs's "ANTINEWS", listing all the functionality you lose by downgrading to the previous version of Emacs. Except in this case, it's actually a "NEWS" file, showing all the functionality you lose by downgrading from systemd to uselessd.
> Certain superfluous unit types removed, namely devices, timers, swaps, mounts and automounts.
So under uselessd a service or socket file cannot depend on the presence of certain mounts, for instance (RequiresMountsFor=). Nor can a service run maintenance tasks periodically with supervision on the maintenance task, and with all the privilege-dropping, isolation, and security features easily accomplished with a systemd service. (And even if a cron implementation implemented such features, they'd work gratuitously differently from systemd services.) Nor can the availability of a device trigger the reliable, monitored launch of a service with all those same systemd features.
> Setup routines for various MAC/ACL systems, including SMACK, IMA and SELinux, are gone. We want to stick to a more clearly defined purpose, one that is agnostic of such elements. Nonetheless, we have retained SELinux access routines in D-Bus APIs and unit options for SMACK attributes in socket unit files to respect existing configurations.
So anyone who actually wants to use such security systems is screwed, then. Good thing Linux isn't about choice.
> systemd-fsck has been replaced with a service file that starts /sbin/fsck to fsck devices. In essence, this isn’t much different from what systemd-fsck already did, but with the overhead of a middle man executable interfacing with /sbin/fsck cut out. This also means that the systemd-defined sysctl parameters for its fsck are gone, and you should use the old ones (/forcefsck, etc.) instead.
So now, in order to force a check of a filesystem on reboot, you must write to that filesystem, potentially doing further damage to it.
This is still a giant WIP and it's quite experimental. We make this perfectly clear in the wiki that it's not ready for system integration or daily use, and there's still a long way to go (including some more radical ideas) before we ever think of making a stable release.
uselessd is about sticking to processes. Did we not make that clear? If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality. Device activation can still be accomplished through (e)udev. We're device node manager-agnostic. We made this clear.
No, you're not screwed. I think you completely ignored the fact that we intend on being portable. This is still early, again, but nonetheless we do compile on FreeBSD and Debian GNU/Hurd and some of the tools (like systemd-delta) actually run properly.
To be honest, we haven't tested the systemd-fsck unit. We mostly removed the binary due to being something that used libudev and looked like it belonged to a shell script more than anything. You can still force fscks through other means (tune2fs for ext2/3/4, etc.) We'll be sorting this out.
It sounds like this project offends your personal ideological sensibilities, as you totally misunderstand its purpose and fail to realize it's a WIP and unstable.
By the way, I liked the jab about choice. I wish we all voted for the same political party, too.
Without being pid 1, that dedicated supervisor needs supervision. Now you have duplicated functionality.
At the same time, said supervisor runs into all kinds of extra problems to ensure proper cleanup of misbehaving services. Supervisord for example is a perfect example of a process monitor is easy to make lose track of the services it's supposed to monitor (I'm not trusting it again). Systemd's use of cgroups for this is for good reason: it's a hard problem to sort out.
You may end up with something usable, but a lot of the Systemd decisions are the ways they are because the alternatives were severely broken. And yes, that includes supervisord and monit.
E.g. here's an example from the Monit website:
check process apache with pidfile /var/run/httpd.pid
start program = "/etc/init.d/apache2 start"
stop program = "/etc/init.d/apache2 stop"
I've lost count of the number of times the Apache init scripts fails to bring Apache reliably up or down, for a variety of reasons, and the assumption that the pid-file will actually contain the pid of Apache or an invalid pid is fundamentally broken (the number of times I've found the pid-space has rolled over quickly enough to cause problems? Not huge, but far from zero), as is the assumption that there won't be other Apache processes in various unpleasant states whose pid is not in the pid file, but which will prevent a restart.
The problem is that Monit is fairly representative for process managers in this respect, most of which makes the (broken) assumption that the init scripts start, stop and restart actions will work reliably, and/or that the pid file contains sane content, and/or that you have a reliable way to kill a process based on holding onto a pid. I've yet to encounter a system where any of those assumptions are true, though you may need to scale up a bit before you start seeing enough of those failures to care.
So the suggestion of using something like monit or supervisord without addressing the amount of functionality you lose if you do makes me question if you understand the purpose of the pieces you are tearing out and/or whether you have put any thought into how users can regain that functionality without ending up making the same tradeoffs systemd does after all.
I'm all for getting something more modular than systemd, but ultimately I think few people will be well served by giving up on the substantial improvements systemd is bringing.
PID files and SysV initscripts are broken. We're well aware and this has been common knowledge for a long time. What I meant was that you can still get more potential from a dedicated program that tries to focus and solve cases in one specific areas. Making a distinction between the init part and the manager/supervisor part is one of our longer term goals with uselessd, beginning with version 5. It's a trade-off.
We understand what we're doing, and we do not deny the presence of warts. When we announce that we're stable and ready for system integration, then we can really talk. As it stands now, this is all preliminary pondering.
Of course it can - you just write a script that checks for the mount being there and if not attempts to mount it, with a timeout, then put it in as a dependency.
Well it isn't called usefuld.
You're not screwed. If you need SMACK, IMA, or SELinux, you still have systemd. That's choice.
http://www.reddit.com/r/linux/comments/2k5b7e/the_concern_is...
"The concern isn’t that systemd itself isn’t following the UNIX philosophy. What’s troubling is that the systemd team is dragging in other projects or functionality, and aggressively integrating them."
(Don't get me wrong, I don't want to flame, I use GNU tools on a daily basis. Just when you know what they mean, the rather unexpected link is pretty funny.)
The full documentation for XY is maintained as a Texinfo manual. If
the info and XY programs are properly installed at your site, the command
info coreutils 'XY invocation'
should give you access to the complete manual.
We have notes in our Bitbucket source.
ps: not native english speaker.
Complimentary means "free", complementary means "goes well with"
"An act, or expression of civility, usually understood to include some hypocrisy, and to mean less than it declares" [Johnson], 1570s, complement, via French compliment (17c.), from Italian complimento "expression of respect and civility," from Vulgar Latin *complire, for Latin complere "to complete" (see complete (adj.)), via notion of "complete the obligations of politeness." Same word as complement but by a different etymological route; differentiated by spelling after 1650.
complimentary (adj.)
1620s, "conveying a compliment," from compliment (n.) + -ary. In later use loosely meaning "free of charge."
complement (n.)
late 14c., "that which completes," from Old French compliement "accomplishment, fulfillment" (14c., Modern French complément), from Latin complementum "that which fills up or completes," from complere "fill up" (see complete (adj.)). Originally also having senses which were taken up c.1650-1725 by compliment.
Now, in my case, I happen to have furthered my distrust of systemd in the process. But that is secondary to just having learned more about what exactly is involved by looking at this.
Still very early days though.
i've lost interest in systemd stuff now. use it. don't use it. whatever