Hi,
On 27-02-19 17:04, Lennart Poettering wrote:
On Mi, 27.02.19 15:56, Hans de Goede (hdego...@redhat.com) wrote:
Hi,
On 27-02-19 12:50, Lennart Poettering wrote:
On Mi, 27.02.19 10:40, Mantas Mikulėnas (graw...@gmail.com) wrote:
On Tue, Feb 26, 2019 at 7:29 PM Hans de Goede <hdego...@redhat.com> wrote:
Hi All,
As part of improving the boot experience:
https://fedoraproject.org/wiki/Changes/FlickerFreeBoot
https://hansdegoede.livejournal.com/20119.html
I took a look at how applying offline updates looks
when pressing ESC to get the detailed view, pk-offline-update
then prints "dnf update" like output, but at the same time
systemd is printing:
[ ***] A start job is running for offline-updates
Messages to the console, the 2 get intermixed and this looks
quite bad and makes the status update of the actual
update process almost impossible to follow.
Is there something which I can put in the
/lib/systemd/system/system-update.target.wants/packagekit-offline-update.service
service file to suppress the knightrider status updates ?
I think the official name is "cylon eye status updates".
Hmm, I *thought* it was possible to disable this by something like
flock()'ing the console device, and systemd-fsck was supposed to do that in
order to avoid the job status from mixing with the "fsck: x% complete"
output. But it looks like that functionality was lost, or never present,
and indeed even systemd-fsck's output is trashed by the "job is running"
messages, from what I remember.
There was a plan to use BSD locks for that. But that was only a
plan. It's listed in the TODO list still though, but noone worked on
that yet.
Looking at source code (manager_get_show_status, unit_needs_console,
exec_context_may_touch_console), the output should be disabled if at least
one currently active unit has a tty as its stdin/stdout, and/or any of the
tty_reset/tty_vhangup options enabled. So maybe StandardOutput=tty,
TTYPath=/dev/console would achieve this?
So, this should work, though is a bit ugly I'd say.
My suggestion would be: the status msg indicates that start-up of the
offline-updates service takes awfully long, i.e. that it apparently
runs everything as Type=oneshot? I find that a curious choice: why
that? Why not use Type=simple or Type=notify or so? i.e. why delay the
boot transaction like this? If you don't then the status message
wouldn't be shown.
Thank you both for your input.
https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html
Says:
"The upgrade scripts should exit only after the update is finished. It is expected
that the service which performs the upgrade will cause the machine to reboot after it is
done. If the system-update.target is successfully reached, i.e. all update services have
run, and the /system-update symlink still exists, it will be removed and the machine
rebooted as a safety measure."
Which AFAIK means that if we make the service consider being "started"
sooner then the system-update.target will be considered reached and the
"the machine <will be> rebooted as a safety measure."
So maybe using StandardOutput=tty + TTYPath=/dev/console is not
such a bad idea in this case?
Another option is to do this in your soruces btw:
```c
(void) kill(1, SIGRTMIN+21);
```
Sending SIGRTMIN+21 to PID 1 will disable the status output
explicitly. If you are sure you don't want it you can just do that, in
one line.
Plymouth also sends that signal, hence make sure you don't run into
races with that.
That won't work, the primary use-case for the offline-updates
status display is a user pressing ESC while plymouth is showing this:
https://fedorapeople.org/~jwrdegoede/flickerfree-videos/installing.png
So that the user can see details if he/she wants that. In this case
plymouth will send SIGRTMIN+22 when switching back to text-mode to
have systemd resume its status messages, so having pk-offline-update send
SIGRTMIN+21 when it starts will not help.
So shall I try using StandardOutput=tty + TTYPath=/dev/console and see
if that works around this for now ?
Regards,
Hans
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
