Resizing mcron job in vm-image.tmpl interferes with settings

  • Done
  • quality assurance status badge
Details
4 participants
  • Ludovic Courtès
  • Mathieu Othacehe
  • Maxim Cournoyer
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
Ludovic Courtès wrote on 9 Aug 2022 11:30
(address . bug-guix@gnu.org)
87r11p932e.fsf@inria.fr
Hello!

Commit 945ad48cd8029fa77a643e00c7fd350e98cacca0 added an mcron job to
‘vm-image.tmpl’ that resets screen size every second. I’m don’t fully
understand the problem this was addressing, but it has two drawbacks:

1. Kicking in every second is inefficient.

2. Resetting the screen size prevents users from changing it. For
example, if I run:

$(guix system vm gnu/system/examples/vm-image.tmpl) -m 1024

then go to the Xfce menu, Settings -> Display, and change the screen
size, I have it immediately reset back to the default value.

Should we remove this workaround, possibly finding another one?

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 9 Aug 2022 11:47
(address . 57068@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87edxp92ai.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (14 lines)
> Commit 945ad48cd8029fa77a643e00c7fd350e98cacca0 added an mcron job to
> ‘vm-image.tmpl’ that resets screen size every second. I’m don’t fully
> understand the problem this was addressing, but it has two drawbacks:
>
> 1. Kicking in every second is inefficient.
>
> 2. Resetting the screen size prevents users from changing it. For
> example, if I run:
>
> $(guix system vm gnu/system/examples/vm-image.tmpl) -m 1024
>
> then go to the Xfce menu, Settings -> Display, and change the screen
> size, I have it immediately reset back to the default value.

There’s a third problem that I initially thought was unrelated:

3. The mcron job starts running before ‘xorg-server’ is up, and that
can cause Xorg to fail to start.

Namely, if you run the command above, you’ll see that Xorg starts and
fails typically a few times in a row, until it eventually succeeds. In
/var/log/messages, you can see that the ‘xorg-server’ process exits with
code 1 (without any indication of what went wrong AFAICS) and the
service gets respawned.

Now if you remove the mcron job and boot the VM, the ‘xorg-server’
service successfully starts. It’s 100% reproducible for me.

I suppose the ‘xrandr’ command can kick in too early while Xorg is
initializing, causing it to exit.

Ludo’.
L
L
Ludovic Courtès wrote on 9 Aug 2022 11:47
control message for bug #57068
(address . control@debbugs.gnu.org)
87czd992a3.fsf@gnu.org
severity 57068 important
quit
L
L
Ludovic Courtès wrote on 9 Aug 2022 11:47
control message for bug #53214
(address . control@debbugs.gnu.org)
87bkst929u.fsf@gnu.org
block 53214 by 57068
quit
M
M
Maxim Cournoyer wrote on 10 Aug 2022 03:14
Re: bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 57068@debbugs.gnu.org)
87v8r0nbm2.fsf@gmail.com
Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (6 lines)
> Hello!
>
> Commit 945ad48cd8029fa77a643e00c7fd350e98cacca0 added an mcron job to
> ‘vm-image.tmpl’ that resets screen size every second. I’m don’t fully
> understand the problem this was addressing, but it has two drawbacks:

The vm-image.tmpl is the template we use for our graphical Guix demo
QEMU image that can be downloaded from our site

This commit was made to allow SPICE dynamic resizing to work, as
mentioned in a comment part of this commit. XFCE lacks support for it,
as also mentioned in the comment
a new user downloading the image and running it in a SPICE-capable
viewer such as virt-manager or gnome-boxes will be dismayed that it
doesn't resize as they may have come to expect from other modern
distributions.

Toggle quote (2 lines)
> 1. Kicking in every second is inefficient.

5% on my machine, as mentioned in the commit message. The trade is
still on the winning side for me (dynamic resizing is a big upgrade for
the user experience in my book).

Toggle quote (8 lines)
> 2. Resetting the screen size prevents users from changing it. For
> example, if I run:
>
> $(guix system vm gnu/system/examples/vm-image.tmpl) -m 1024
>
> then go to the Xfce menu, Settings -> Display, and change the screen
> size, I have it immediately reset back to the default value.

OK. I didn't know this could be workable use case with the stock QEMU
viewer when playing with graphical VMs.

Toggle quote (2 lines)
> Should we remove this workaround, possibly finding another one?

I think we should use a desktop environment that is better maintained,
and which works well with SPICE, without hacks, given the improvements
to the user experience it provides, and given it's important that a
first user encounter with Guix be smooth and shiny. GNOME could do it,
at the cost of a bigger image size.

There are other, perhaps worst issues with XFCE, which is that the
keyboard layout switcher doesn't work, and it didn't seem trivial to fix
when I looked at it.

What do you think?

Thanks,

Maxim
M
M
Maxim Cournoyer wrote on 10 Aug 2022 06:46
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 57068@debbugs.gnu.org)
87wnbgln8z.fsf@gmail.com
Hi,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (30 lines)
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> Commit 945ad48cd8029fa77a643e00c7fd350e98cacca0 added an mcron job to
>> ‘vm-image.tmpl’ that resets screen size every second. I’m don’t fully
>> understand the problem this was addressing, but it has two drawbacks:
>>
>> 1. Kicking in every second is inefficient.
>>
>> 2. Resetting the screen size prevents users from changing it. For
>> example, if I run:
>>
>> $(guix system vm gnu/system/examples/vm-image.tmpl) -m 1024
>>
>> then go to the Xfce menu, Settings -> Display, and change the screen
>> size, I have it immediately reset back to the default value.
>
> There’s a third problem that I initially thought was unrelated:
>
> 3. The mcron job starts running before ‘xorg-server’ is up, and that
> can cause Xorg to fail to start.
>
> Namely, if you run the command above, you’ll see that Xorg starts and
> fails typically a few times in a row, until it eventually succeeds. In
> /var/log/messages, you can see that the ‘xorg-server’ process exits with
> code 1 (without any indication of what went wrong AFAICS) and the
> service gets respawned.
>
> Now if you remove the mcron job and boot the VM, the ‘xorg-server’
> service successfully starts. It’s 100% reproducible for me.

I tried to reproduce the problem without any luck on my machine (it
always boots fine). Odd.

I don't mind the hack removed, but I think we should aim to keep SPICE
dynamic resizing working, and currently that'd mean switching desktop
environment, unless we fix
adjusted for the years old change in SPICE with
in case your looking for something fun to hack on :-).

Thanks,

Maxim
L
L
Ludovic Courtès wrote on 11 Aug 2022 12:30
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 57068@debbugs.gnu.org)
87zggbvzrd.fsf@gnu.org
Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (17 lines)
>> There’s a third problem that I initially thought was unrelated:
>>
>> 3. The mcron job starts running before ‘xorg-server’ is up, and that
>> can cause Xorg to fail to start.
>>
>> Namely, if you run the command above, you’ll see that Xorg starts and
>> fails typically a few times in a row, until it eventually succeeds. In
>> /var/log/messages, you can see that the ‘xorg-server’ process exits with
>> code 1 (without any indication of what went wrong AFAICS) and the
>> service gets respawned.
>>
>> Now if you remove the mcron job and boot the VM, the ‘xorg-server’
>> service successfully starts. It’s 100% reproducible for me.
>
> I tried to reproduce the problem without any luck on my machine (it
> always boots fine). Odd.

Does ‘xorg-server’ successfully start from the first time, or does
succeed after a few tries? For me it systemically tries a couple of
time before it succeeds.

Ludo’.
L
L
Ludovic Courtès wrote on 11 Aug 2022 12:36
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 57068@debbugs.gnu.org)
87sfm3vzgl.fsf@gnu.org
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (14 lines)
> The vm-image.tmpl is the template we use for our graphical Guix demo
> QEMU image that can be downloaded from our site
> (https://guix.gnu.org/en/download/ ->
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2).
>
> This commit was made to allow SPICE dynamic resizing to work, as
> mentioned in a comment part of this commit. XFCE lacks support for it,
> as also mentioned in the comment
> (https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/142), which means
> a new user downloading the image and running it in a SPICE-capable
> viewer such as virt-manager or gnome-boxes will be dismayed that it
> doesn't resize as they may have come to expect from other modern
> distributions.

Understood.

(I wonder if the QEMU Guest Agent can serve a similar purpose.)

Toggle quote (4 lines)
>> Should we remove this workaround, possibly finding another one?
>
> I think we should use a desktop environment that is better maintained,

I think this is unfair criticism: Xfce is actively maintained, with a
large user base.

Toggle quote (5 lines)
> and which works well with SPICE, without hacks, given the improvements
> to the user experience it provides, and given it's important that a
> first user encounter with Guix be smooth and shiny. GNOME could do it,
> at the cost of a bigger image size.

Right. I wouldn’t mind GNOME, but one reason we went for Xfce is that
GNOME is just too big, at least as currently packaged in Guix.

Toggle quote (4 lines)
> There are other, perhaps worst issues with XFCE, which is that the
> keyboard layout switcher doesn't work, and it didn't seem trivial to fix
> when I looked at it.

Oh, I wasn’t aware of that, that should certainly be fixed. (I fixed a
similar issue in GNOME some years ago, and I’m confident it’ll be easier
to fix in Xfce because it doesn’t have all those layers and daemons and
JavaScript and DBus interfaces. :-))

That’s a general issue with all Xfce installations, not just in the VM
image, right?

Thanks,
Ludo’.
M
M
Mathieu Othacehe wrote on 1 Nov 2022 18:40
(name . Ludovic Courtès)(address . ludo@gnu.org)
87v8nylgig.fsf@gnu.org
Hey,

Toggle quote (5 lines)
> Oh, I wasn’t aware of that, that should certainly be fixed. (I fixed a
> similar issue in GNOME some years ago, and I’m confident it’ll be easier
> to fix in Xfce because it doesn’t have all those layers and daemons and
> JavaScript and DBus interfaces. :-))

Fixing this behaviour in Xfce seems like the right thing to do to
conserve SPICE support and fix the QEMU resizing issue.

This also looks like a large development, so I propose to unblock the
release with this ticket.

Thanks,

Mathieu
M
M
Mathieu Othacehe wrote on 1 Nov 2022 18:41
control message for bug #53214
(address . control@debbugs.gnu.org)
87tu3ilght.fsf@meije.mail-host-address-is-not-set
unblock 53214 by 57068
quit
L
L
Ludovic Courtès wrote on 3 Nov 2022 15:59
Re: bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
87pme4qe2u.fsf@gnu.org
Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (11 lines)
>> Oh, I wasn’t aware of that, that should certainly be fixed. (I fixed a
>> similar issue in GNOME some years ago, and I’m confident it’ll be easier
>> to fix in Xfce because it doesn’t have all those layers and daemons and
>> JavaScript and DBus interfaces. :-))
>
> Fixing this behaviour in Xfce seems like the right thing to do to
> conserve SPICE support and fix the QEMU resizing issue.
>
> This also looks like a large development, so I propose to unblock the
> release with this ticket.

I agree, but it would be nice to find another workaround: invoking
xrandr every second is undesirable. It interferes with user settings
and degrades performance, whether or not one uses SPICE.

Can the guest determine whether SPICE is being used? That would allow
us to make the hack conditional.

Ludo’.
M
M
Maxim Cournoyer wrote on 30 Dec 2023 06:35
(name . Ludovic Courtès)(address . ludo@gnu.org)
87o7e8qmlq.fsf@gmail.com
Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (22 lines)
> Hi,
>
> Mathieu Othacehe <othacehe@gnu.org> skribis:
>
>>> Oh, I wasn’t aware of that, that should certainly be fixed. (I fixed a
>>> similar issue in GNOME some years ago, and I’m confident it’ll be easier
>>> to fix in Xfce because it doesn’t have all those layers and daemons and
>>> JavaScript and DBus interfaces. :-))
>>
>> Fixing this behaviour in Xfce seems like the right thing to do to
>> conserve SPICE support and fix the QEMU resizing issue.
>>
>> This also looks like a large development, so I propose to unblock the
>> release with this ticket.
>
> I agree, but it would be nice to find another workaround: invoking
> xrandr every second is undesirable. It interferes with user settings
> and degrades performance, whether or not one uses SPICE.
>
> Can the guest determine whether SPICE is being used? That would allow
> us to make the hack conditional.

I've discovered we could use udev to invoke xrandr only on resizing
events, crafted a custom Guile script, and used it to fix this with
commit 1d4db94bebba ("gnu: vm-image.tmpl: Improve SPICE dynamic
resizing.").

I've tested the automatic resizing works with virt-manager and GNOME
Boxes, and that nothing happens when using QEMU (the script still runs,
consuming 14 MiB of RSS about, but that's it).

--
Thanks,
Maxim
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 57068@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 57068
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch