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

OpenSubmitted by Ludovic Courtès.
Details
2 participants
  • Ludovic Courtès
  • Maxim Cournoyer
Owner
unassigned
Severity
important
L
L
Ludovic Courtès wrote on 9 Aug 11:30 +0200
(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 11:47 +0200
(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 11:47 +0200
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 11:47 +0200
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 03:14 +0200
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 06:46 +0200
(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 12:30 +0200
(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 12:36 +0200
(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’.
?