Picom (X Compositor) crashed too many times. Its autorestart has been disabled until next login.

Bug #2018620 reported by sudodus
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
lubuntu-default-settings (Ubuntu)
Fix Released
High
Dan Simmons
picom (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

When booting into a persistent live system made by mkusb (dus-iso2usb), when booting in BIOS mode alias legacy mode, I get a pop-up window with the text "Picom (X Compositor) crashed too many times. Its autorestart has been disabled until next login."

I tested various tools, and they seems to work as usual.

Maybe picom is not necessary? What should I look for?

ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: picom 10.2-1
ProcVersionSignature: Ubuntu 6.2.0-21.21-generic 6.2.6
Uname: Linux 6.2.0-21-generic x86_64
ApportVersion: 2.26.1-0ubuntu3
Architecture: amd64
CasperMD5json:
 {
   "result": "skip"
 }
CasperVersion: 1.481
CurrentDesktop: LXQt
Date: Fri May 5 17:54:23 2023
LiveMediaBuild: Lubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230505)
SourcePackage: picom
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
sudodus (nio-wiklund) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in picom (Ubuntu):
status: New → Confirmed
Revision history for this message
Leó Kolbeinsson (leok) wrote (last edit ):

Confirm that this also occurs after installation in a VirtualBox running in BIOS mode.

A second test on a barebone machine running in UEFI+secure boot mode - no error encountered.
The installation media was created with "start up disk creator" on a machine running Lubuntu 23.04 Lunar.

Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
https://iso.qa.ubuntu.com/qatracker/reports/bugs/2018620

tags: added: iso-testing
Revision history for this message
sudodus (nio-wiklund) wrote :

Further testing in the same computer a Dell Precision M4800, this time with a *normal cloned live USB drive*. It seems to behave in the same way:

The first time there is no pop-up complaint about picom, but the second time it happens.

Now we must remember that the Lubuntu live system is not truly live, because a partition labeled 'writable' is created the first time, and log files and crash dumps are written into it. I suspect that this makes a difference. Otherwise the live system should behave in the same way when booted after shutdown.

Next I booted the cloned drive live-only by adding the boot option 'nopersistent', and there is no pop-up complaint about picom.

Next I booted live without and extra boot option and there was no popup complaint. I repeated booting like this and the complaint was gone. So things seem flaky. Is this caused by some race condition or by some cruft that is not cleared at boot? It would be interesting to get results from other computers.

Revision history for this message
sudodus (nio-wiklund) wrote :

Thanks Leo for confirming the bug :-)

Revision history for this message
Chris Guiver (guiverc) wrote :

I don't notice any issues on my primary (installed) box.. but booting a daily on
- hp prodesk 400 g1 sff (i5-4570, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

and this issue appears on first boot of this mantic daily.

Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote :

I had no issue in live, but I found the problem when loading a freshly installed daily in VirtualBox in UEFI mode with VMSVGA graphics.

Run `picom` on the command line and you get a "FATAL ERROR:" "Another composite manager is already running." However, there's none that I can tell of.

Upstream I see only one related bug and it's a Wayland incompatibility. We're still running X, so that's not the issue.

I see we don't have a configuration file. I tried to add one to $HOME/.config/picom.conf with one simple directive ("shadow = true;") and that had no effect.

Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote (last edit ):

So I did some more testing with this and found that as of today's daily (20230621):
 * live BIOS: no error
 * live EFI: no error
 * installed BIOS: no error
 * installed EFI: ERROR!

It's a little odd to me that I have no issues with the BIOS modes though other folks were complaining that the issue existed solely there.

Can other folks confirm these results for the same four conditions in VirtualBox?

Also, can we do more real hardware testing?

FWIW I'm running a slightly older version (7.0.0) which could be part of the reason why I can't reproduce the exact same behavior.

Also, curiously, at least with the recent daily, `pgrep picom` did produce a result, which means it's running, which is to say that the error about crashing is erroneous?

(An aside: I needed to use the UEFI shell to boot the daily today; bizarre!)

Revision history for this message
Lyn Perrine (walterorlin) wrote (last edit ):

I get no error on a virt-manager VM with bios on an already installed mantic vm.
I installed a mantic uefi vm also on virt manager and didn't get the crash of picom.

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Tested in VirtualBox (7.0.6) and results here:

*live BIOS - error
*live EFI - error
*installed BIOS - no error
*installed EFI - no error

N.B
I have been testing daily ISO´s on a regular basis and my experience is that this error is very random indeed.I have recorded the results on the QA tracking site but have not complied them separately.My tests have been in both VM's and barebone hardware - on the barebones the issue appears to be more random - but yes does occur on first boot before install in some cases.

Expect to test further next few days and add results to this bug report.

Revision history for this message
Leó Kolbeinsson (leok) wrote :

Performed further tests on barebone hardware Daily Lubuntu Mantic ISO dated 21-06-2023

Dell 7060 machine live boot UEFI+secure boot mode – no error
Dell 7060 machine install UEFI+secure boot mode – no error

Awow NY41 machine live boot UEFI+secure boot mode – no error
Awow NY41 machine install UEFI+secure boot mode – no error

Dell 7280 machine live boot BIOS mode – no error
Dell 7280 machine install BIOS mode – no error
Dell 7280 machine live boot UEFI mode – no error
Dell 7280 machine install UEFI mode – no error

After finishing the tests – ran one last Live session on the above mentioned Dell 7280 and this time received the Picom error after booting into desktop!!

Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote :

I'm running some tests across multiple installs on the same conditions but I wanted to point out an observation. Though the error suggests picom has crashed too many times, it is still running. Similarly, looking at session settings, despite what the error says, it has NOT been disabled in autostart. Weird.

Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote (last edit ):

Another aside for those folks that may want to try to get more information in an installed system— turn on logging like so:

 1. create $XDG_CONFIG_HOME/picom.conf
 2. edit the file and include the following lines:
    log-level = "error"
    log-file = "/path/to/picom.log"

Upon restart of picom, logging will appear in the specified log file. Note that using a variable in the path such as "$XDG_CONFIG_HOME/picom.log" seems to silently fail, so make sure to use a full absolute path such as "/home/lubuntu/.config/picom.log." Note that if you want to really get a lot of info, "log-level" could be set to "debug" or "trace."

Since we're on the subject of configuring picom, there is a fork of compton-conf (the GUI tool) called picom-conf. This might be worth packaging and including in the seed:
https://github.com/redtide/picom-conf

Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote (last edit ):

Yes, this is very inconsistent. I did 5 live tests before doing 5 installs (themselves including 5 additional live tests) with 5 reboots each (with 1 exception) for a total of 36 tests. Here's the results:

 * BIOS live: 0 errors/10 tests
 * BIOS installs:
    1. 0 errors (I actually didn't reboot this one after it succeeded the first time; an oversight)
    2. 1 error/5 tests (1st boot; this one also had some weird X issues so might have been a bad install)
    3. 2 errors/5 tests (3rd/4th boots)
    4. 2 errors/5 tests (1st/5th boots)
    5. 4 errors/5 tests (all but 3rd boots)

It seems every time the error occurs, 5 lines are added to a debug log, all the same (except for timestamp):
 [ 06/23/2023 15:02:26.319 session_init FATAL ERROR ] Another composite manager is already running

My guess is that something is triggering picom to run outside of the autostart. Depending on the order of how things run, sometimes the autostart runs before whatever this thing is and sometimes it doesn't. The other composite manager is, of course, picom itself.

To test this, I turned off the autostart in Session Settings. This has an effect of creating a new desktop file in $XDG_CONFIG_HOME with the key "Hidden=True," which has the effect of ignoring all desktop files with the same name. This should cause picom not to start, in other words. This should override the desktop file provided by the picom package in /etc/xdg/autostart.

Curiously, picom was running when I restarted. How?

Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote (last edit ):

Found it. /etc/xdg/xdg-Lubuntu/autostart/lxqt-picom.desktop (note the different name) provided by the lubuntu-default-settings package. To confirm it's what was starting picom, I renamed it to picom.desktop. To explain this, remember I said before that making one desktop file in $XDG_CONFIG_HOME have the "Hidden=True" key would cause all other desktop files *with the same name* in any other autostart directory to be ignored. Restarted and no picom running.

Why session settings doesn't pick up on this is beyond me. It seems to me we should probably get rid of the file in lubuntu-default-settings since the picom package is already providing it.

Perhaps instead we should have a desktop file in /usr/share/Lubuntu/applications with "NotShowIn=LXQt" so that it doesn't show up in the menu. Of course, vim is in there as is TexInfo, so maybe we don't care?

Revision history for this message
Chris Guiver (guiverc) wrote :

I'm doing a live QA-test on
- sony vaio ultrabook svp11216cgb (i5-9400u, 4gb, intel haswell-ULT)

the system was booted; but I got called away, thus the system was left idle for some time... when I came back it was still idle with black screen, on waking screensaver I got the PICOM IS CRASHED message.

Nothing is evident in /var/crash, I don't see anything in dmesg or journactl that's useful

http://iso.qa.ubuntu.com/qatracker/milestones/446/builds/282764/testcases/1303/results is my test results; but I'm going to ignore the message as I don't see a problem, except for the message itself.

Dan Simmons (kc2bez)
Changed in lubuntu-default-settings (Ubuntu):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Dan Simmons (kc2bez)
milestone: none → ubuntu-23.10-feature-freeze
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lubuntu-default-settings - 23.10.1

---------------
lubuntu-default-settings (23.10.1) mantic; urgency=medium

  * Remove Picom autostart so it doesn't start twice, thanks wxl.
    (LP: #2018620)

 -- Dan Simmons <email address hidden> Tue, 15 Aug 2023 07:14:21 -0400

Changed in lubuntu-default-settings (Ubuntu):
status: Confirmed → Fix Released
Changed in picom (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote :

Made the bug invalid against Picom because it's not the problem child here, as aforementioned.

Loaded up the 20230815 ISO and found that I was on lubuntu-default-settings 23.10.1. I checked and /etc/xdg/xdg-Lubuntu/autostart/lxqt-picom.desktop was indeed missing. Picom was also running.

Did an install and rebooted five times and no error.

Calling it solved.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.