Comment 15 for bug 2018620

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?