[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Another system management tool to disappear.

On 2015-08-31 at 13:25, David Wright wrote:

> Quoting The Wanderer (wanderer@fastmail.fm):
>> Debian could not have chosen systemd if Lennart had not written it,
>> and Debian could not have chosen systemd-in-its-current-form if
>> Lennart had not designed it in that form, so some layer of the
>> blame does fall on him.
> That's a very interesting argument. Can we apply it to Presidents'
> parents?

A person's parents do not design or define that person. They have input,
which is not to be entirely discounted - but even on the assumption that
"nature vs. nurture" gets resolved entirely in favor of nurture, there
are many other sources for "nurture" than just the parents.

Plus, of course, a person has a mind of his/her/etc. own, which a
program or set of programs does not. (Barring AI or obscure arguable
corner cases, anyway.)

All that aside, blaming parents does happen in the real world - things
like "you didn't raise that boy right" appear often enough in certain
parts of the culture.

>> There are plenty of reports of systems which worked just fine with
>> a given configuration which do not work with that configuration
>> after being transitioned to systemd; for one easy non-cosmetic
>> example (there are apparently others), consider the "a failed mount
>> which is not explicitly marked for failures to be ignored will
>> result in a failed boot" behavior, which did not occur without
>> systemd but does happen with systemd.
>> Yes, you can change your system's configuration to make it work,
>> but in a stable system you shouldn't have to. (And I'm not talking
>> about "stable" in the sense of the Debian repository codenames; I'm
>> talking about 'stable" in the larger sense.)
> I can't see what's wrong with adding new features or with changing 
> defaults. Your example was documented in the release notes.

I was speaking to the claim that systemd represented a lack of
stability, vs. the claim that no instability had been seen because of
systemd. (Paraphrasing in both cases.)

Adding new features, while remaining 100% backwards compatible, is not
ordinarily a problem - except inasmuch as doing so has side effects like
increasing footprint or increasing attack surface, which is a separate

Changing defaults isn't inherently a problem either (although I have an
entire other discussion there), but it's difficult to claim that such a
change is stable behavior.

>> On a more cosmetic level, without systemd, if you use a "quiet"
>> option on the kernel command line you will silence kernel output
>> during boot but not silence service-startup (etc.) option during
>> the later stages of the bootstrap process - but with systemd, using
>> that option silences both kernel output _and_ service-startup
>> (etc.) output..
>> Yes, you can add half-a-dozen-ish systemd-specific options on the
>> kernel command line to get systemd to display the same combination
>> of output types as would have happened by default without systemd -
>> but if you have to change your system configuration in order to get
>> the same behavior, that system is not behaving in a stable
>> fashion.
> All I've added to /etc/default/grub is   systemd.show_status=true
> which gives me about the same level of output from booting as before.
> (A bit more, it's true: eg it says both starting and started for each
> service, and the granularity is finer.)

Hmm. Maybe I'm remembering wrong; I thought that when people complained
about this before, the documentation to which they were pointed listed
various individual options to re-enable various different types of boot
messages separately. I did not see one to enable the messages en-masse
which would not also enable the messages which the original 'quiet'
option would have silenced. If such an option does exist and function,
that blunts this example pretty solidly.

>> Also on a mostly-cosmetic level, if you log in at a text console
>> without systemd, you will get a certain set of messages, coming
>> mostly from login and from your shell - but with systemd, logging
>> in at a text console also produces a mess of extra messages coming
>> from logind, which are largely irrelevant to whoever just logged in
>> and which step all over either the original set of messages or the
>> actual shell prompt.
>> As far as I've been able to determine, there is no way to get
>> logind to not produce these messages, without also preventing it
>> from producing messages later - or in background logging - which
>> you might actually want. And, if I'm interpreting the situation
>> correctly, you will probably see these messages in your console
>> every time _anyone_ gets a new "session" on that computer, even if
>> it's not you. This is the final-straw behavior which led me to
>> reject systemd for my own systems.

(For clarification, the reason this was the final straw was that it
meant I could not simply ignore the presence of systemd entirely for
normal use, since this would push it into my attention on every console

> I've tried to work out what you're talking about here. Here's a 
> comparison of my (admittedly rather noisy) VC login on two systems:
> west!david 12:22:14 ~ $ diff -U0 VC-login-*[ey]
> --- VC-login-jessie     2015-08-31 11:34:23.476573261 -0500
> +++ VC-login-wheezy     2015-08-31 11:38:11.000000000 -0500

How did you get these files? I haven't been able to come up with a way
to get a dump of the exact text that is on a console, short of manually
typing it into an editor (probably on another computer, for
convenience's sake). Parts of it are logged, but not as far as I can
tell into a single file, and I would actively expect that the text I'm
objecting to would get logged separately (if at all) in any case.

I haven't done a full detailed analysis of exactly what happens yet,
but the first time I log in on my laptop after boot, I get the following
(retyped, timestamps and other unique numbers mangled, one line of
context included):

No mail.
[  123.123456] systemd-logind[1234]: New seat seat0.
[  123.234567] systemd-logind[1234]: Watching system buttons on
/dev/input/event4 (Power Button)
[  123.123678] systemd-logind[1234]: Watching system buttons on
/dev/input/event5 (Video Bus)
[  123.123789] systemd-logind[1234]: Watching system buttons on
/dev/input/event1 (Power Button)
[  123.124012] systemd-logind[1234]: Watching system buttons on
/dev/input/event3 (Lid Switch)
[  123.124123] systemd-logind[1234]: Watching system buttons on
/dev/input/event2 (Sleep Button)
[  123.134567] systemd-logind[1234]: Failed to start user service:
Unknown unit: user@1000.service
[  123.138901] systemd-logind[1234]: New session 1 of user foobar.
This line was printed by the fortune program, called by ~/.bashrc.

On later logins as the same user without rebooting, I get only the "New
session X of user foobar" message, which is still bad enough but doesn't
deserve the description "a mess of messages".

Similarly, on logging out of that session, I get the following at the
login prompt:

foobar login: [1234567.123456] systemd-logind[1234]: Removed session 1.

and the cursor for the login prompt appears on the next line, rather
than appearing immediately after the 'hostname login: ' text. (The
message from logind does not appear instantly after logout; if I start
typing a username quickly enough, this will get printed in the middle of
the username, thus completely confusing display of what has and has not
already been typed.)

This is potentially useful information to see in log files, and if the
single "new session X of user foobar" line does get printed to all
active consoles every time _anyone_ starts a new session (I still
haven't tested that), there are circumstances where it might even be
useful to have the immediate heads-up alert that "hey, someone else just
logged in to your system!" - but it should not be being printed when the
user logs in or out, especially not if it's going to step on the login

Note that this is on a system with only some parts of "the systemd
suite" present, and with systemd _not_ running as PID1. (I apologize for
not mentioning that earlier; it's been long enough since I was changing
any related part of this laptop's config that I didn't remember the
exact details of how I'd left it.) Specifically:

$ dpkg -l "*systemd*" | grep ii
ii  libpam-systemd:amd64      224-1        amd64        system and servi
ii  libsystemd0:amd64         224-1        amd64        systemd utility
ii  libsystemd0:i386          224-1        i386         systemd utility
ii  systemd                   224-1        amd64        system and servi
ii  systemd-shim              9-1          amd64        shim for systemd

   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: