This should make sure our log lines look nice even if the tty we are
connected to is in raw mode. Normally, it's the TTY's job to turn an NL
we output into a CRNL and interpret it accordingly. However, if the tty
is in "raw" mode it won't do that. Specifically, this is controlled by
the ONLCR flag on the TTY. A TTY might be in raw mode if our "ptyfwd"
logic is used for example, where a 2nd tty is bi-directionally connected
to the primary tty, and duplicate processing is not desired.
Hence, let's just write out the CR on our own. This will make sure that
whenever we output something subsequent output always continues on the
beginning of the next line again, regardless the mode the TTY is in. Of
course, if the TTY is *not* in raw mode, then the extra CR we now
generate is redundant, but it shouldn't hurt either, as it just moves
the cursor to the front of the line even though already is just there.
We only to that if we actually talk to a TTY though, since we don't want
the extra CRs if we are redirected to a pipe or file or so. We are not
on Windows after all.
Fixes: #30155
This fixes a regression caused by 5ed73478e1
and aa6123e85e.
With these commits, when Reboot dbus method or friends is called,
reset_scheduled_shutdown() is called before shutting down the system,
so the wall message was cleared.
As the wall message itself is unrelated to the scheduling of shutting
down systems, let's keep the message.
Fixes#30167.
The only reason to recommend this would be if people had multiple commands
with the same name in the search path. This probably was never the best idea,
and it happens rarely anyway. Since the patch that dropped requirement for full
paths was introduced, we have dropped support for unmerged-usr and we're planning
to drop support for split-bin at some point too. Many people effectively have just
one directory in the search path, so there is even less reason to use an absolute
path. So let's recommend just using the command name, which makes the unit file
shorter and nicer to read.
An event loop is not "synchronous". So we shouldn't say that the client must
"synchrounusly poll" if we recommend an event loop. Let's just say it should
poll, and say that "sd_bus_wait()" is blocking, which is clearer and more
correct than "synchronous".
I started working on integrating this in the Fedora package and realized that
the example files should be installed regardless of the renamed files when
default-network=true is used. This is because the renamed files become part of
a different package, and we want to have the other files which are used as
documentation in the main package anyway.
Follow-up for 93f1da4556
and 8ea288db01
Before the offending commits, we only read the first found
main config file. If the main config file is symlinked to/as
a drop-in, we should break instead of continuing, for it to
be read later.
Let's try to recognize paths (i.e. those with a "/") as source for
credentials to load, and then read them from the file system. Also, only read
credentials from an inbound credentials directory if the source
qualifies as valid credential name.
Otherwise print a nice error.
We must check the return value of GREEDY_REALLOC for OOM, and the
pointer are updated already on success, hence it's a bad idea to make a
copy of the pointer beforehand.
Let's disable ECHOPRT for terminals we reset.
The feature only really makes sense for hardcopy terminals and we sure
as shit don't talk to one of those. It has the effect that when line
editing is on and you hit backspace it outputs "\" followed by the
removed character. This never makes sense on a TTY that can just erase
the character.
Hence turn of this flag.
We have carried this flag along for about forever, but it doesn't really
make sense. I guess we mostly tested the terminal reset stuff for output
only, not for input.
This change is in particular useful for tools such as
"systemd-firstboot" which interactively ask questions on the console,
and where line editing should really work.
The logic is taken from dump ratelimit: if the config changes, we discard the
counters. This allows the user apply new limits and "start from scratch" in
that case.
This actually makes StartLimitIntervalSec=infinity (or with a large interval)
work as expected, because the counter is maintained even if daemon-reload
operations are interleaved.