[SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

Polarity · 2019-10-01 14:59:58

I have a problem with a plugin (Optical Flares for Nuke in case this is interesting/relevant) that I can barely use due to this problem:

The plugin has a button that should open a new window with a variety of settings. However, this window never opens and the following is the console output when I try to do so:

("*OF*" signals that this message is from the plugin directly)

*OF* Logging Enabled
*OF* Welcome to Optical Flares for NUKE 1.0.86, Instance ID: 0
*OF* Creating Instance: 0 **********
Invalid MIT-MAGIC-COOKIE-1 key
*OF* Unable to init X11!

Also this line but i don't think it is relevant here:

libpng warning: Application built with libpng-1.4.8 but running with 1.6.34

I've seen that the .Xauthority file in the home folder is empty. This is likely because $XAUTHORITY = /run/user/1000/gdm/Xauthority
This is not empty and contains some (binary?) data. (Unreadable) As well as the string "MIT-MAGIC-COOKIE-1".

This is as much as I can find out at this point, but I don't know what to do with it and even less how to solve this issue. As far as I understand it, X is refusing to serve a connection to the plugin, so no window can be created.

I'd be very glad if someone could point me in the right direction here. Thank you!

Last edited by Polarity (2019-10-02 20:39:32)

seth · 2019-10-01 17:44:40

You're probably on a wayland session and xwayland isn't installed or for some reason not launched or not sufficient for the plugin?

loginctl session-status

Polarity · 2019-10-01 18:01:30

Thanks for your reply!

No, I am on X. (nvidia)

         Leader: 1431 (gdm-session-wor)
            Seat: seat0; vc2
             TTY: tty2
         Service: gdm-password; type x11; class user
           State: active
            Unit: session-2.scope
                  ├─1431 gdm-session-worker [pam/gdm-password]
                  ├─1450 /usr/bin/gnome-keyring-daemon --daemonize --login
                  ├─1455 /usr/lib/gdm-x-session --run-script /usr/bin/gnome-session
                  ├─1457 /usr/lib/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3
                  └─1462 /usr/lib/gnome-session-binary

Side note: Also, is it normal that my system defaults to TTY2?

seth · 2019-10-01 18:50:06

For GDM, yes.
The plugin then might simply have ahrdcoded the xauthority path, you could symlink ~/.Xauthority to /run/user/1000/gdm/Xauthority and see what happens.

Polarity · 2019-10-01 20:39:17

Hm... I tried it, but no difference. Good idea though!

Is there a way to get more insight on what's going on within X?

seth · 2019-10-02 08:06:35

You could route X11 through tcp and engage a portscanner, but that would alter the behavior as well.

strace -f <process> 2>&1 | grep -i authority

would reveal which Xauthority files are considered and opened.

A common cause for authority failures is an unconfigured hostname (and NM alters it late), but that would break every subsequent X11 client.

Ultimately you could test "xhost +" before running the program to see whether this is an authority issue at all or a red herring (at this point the X11 server is open to the world, though by default not via tcp, ie. only random local connections from any user. "xhost -" closes it again)

Polarity · 2019-10-02 12:36:44

[pid 66773] access("/run/user/1000/gdm/Xauthority", R_OK) = 0
[pid 66773] openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 6
[pid 66773] access("/run/user/1000/ICEauthority", R_OK) = 0
[pid 66773] openat(AT_FDCWD, "/run/user/1000/ICEauthority", O_RDONLY) = 24
[pid 66773] access("/run/user/1000/ICEauthority", R_OK) = 0
[pid 66773] openat(AT_FDCWD, "/run/user/1000/ICEauthority", O_RDONLY) = 24
[pid 66773] access("/run/user/1000/ICEauthority", R_OK) = 0
[pid 66773] openat(AT_FDCWD, "/run/user/1000/ICEauthority", O_RDONLY) = 24
[pid 66773] access("/run/user/1000/ICEauthority", R_OK) = 0
[pid 66773] openat(AT_FDCWD, "/run/user/1000/ICEauthority", O_RDONLY) = 24
[pid 66773] access("/run/user/1000/gdm/Xauthority", R_OK) = 0
[pid 66773] openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 129
[pid 66773] access("/run/user/1000/gdm/Xauthority", R_OK) = 0
[pid 66773] openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 134

This seems ok.

I also tried running it after "xhost +". - Everything remained the same. I even got the same error messages which seems odd.

Invalid MIT-MAGIC-COOKIE-1 key
*OF* Unable to init X11!

Shouldn't that have gone away after "xhost +"?

So, this basically rules out any Xauthority issues, right?

The only other clue would be libpng then.
I've already set Nuke and the Plugin to the hightest verbosity levels. There seems to be nothing else.

Thank you for your help and explanations!

Polarity · 2019-10-02 12:57:50

I just tried and straced libpng.

openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC) = 3
[pid 84415] openat(AT_FDCWD, "/usr/lib/libpng16.so.16.37.0", O_RDONLY) = 11
[pid 84415] openat(AT_FDCWD, "/usr/lib/libpng16.so.16.37.0", O_RDONLY) = 11
[pid 84415] openat(AT_FDCWD, "/usr/lib/libpng16.so.16.37.0", O_RDONLY) = 11
[pid 84429] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 84429] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC) = 5
[pid 84569] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 84569] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 84569] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC) = 5
[pid 84650] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84650] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84650] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84652] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84652] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84652] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84654] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84654] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84654] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84656] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84656] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84656] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84658] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84658] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84658] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84662] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84662] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84662] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84664] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84664] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84664] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84674] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84674] openat(AT_FDCWD, "/usr/local/Nuke11.3v5/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84674] openat(AT_FDCWD, "/usr/lib/libpng16.so.16", O_RDONLY|O_CLOEXEC <unfinished ...>
[pid 84415] write(2, "libpng warning: Application buil"..., 75libpng warning: Application built with libpng-1.4.8 but running with 1.6.37) = 75

EDIT: I just remembered that I ran the whole thing with libpng14 in the past and the warning actually went away. But still no UI Window.

Last edited by Polarity (2019-10-02 13:22:32)

seth · 2019-10-02 13:55:52

Here's a hail-mary: iirc GDM keeps an extra server, check "echo $DISPLAY" - if that's not ":0.0" the plugin might talk to the GDM X11 server.
The test would be to skip GDM and try startx/xinit: https://wiki.archlinux.org/index.php/Xinit#xinitrc (pay attention to the violet notes)

Last edited by seth (2019-10-02 13:56:05)

Polarity · 2019-10-02 17:15:50

Interesting! $DISPLAY is in fact ":1"

However I'm not exactly sure what to do here, sorry. How would I modify .xinitrc ?

I copied the xinitrc which looks like this:

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then







    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then







    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

twm &
xclock -geometry 50x50-1+1 &
xterm -geometry 80x50+494+51 &
xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login

I'd expect to see GDM somewhere but this is already twm.

seth · 2019-10-02 19:24:32

twm is a window manager, remove it and the following lines (starting a bunch of xterms) and see https://wiki.archlinux.org/index.php/GN … g_sessions

Polarity · 2019-10-02 20:01:45

HOLY COW! That just worked! I got the UI for the first time ever!

Thank you so much for your help! (and patience )

What's the permanent solution here? Live without GDM? Or can I reconfigure something somewhere so applications can't open windows in nirvana anymore?

seth · 2019-10-02 20:20:08

The plugin has the display probably hardcoded to :0.0 somewhere. I don't think you can prevent GDM from using a second X11 server for the session, but other DM (eg. xdm) won't do this.
nb. that a DM is only really (somewhat) required if this is a real™ multi-user system (or you want to use different session types)
Otherwise you could acutally boot straight into a locked (gnome) session, unlock w/ your creds and be done (you'll need a different screen locker, though - eg. xscreensaver or i3lock or slock etc. see the gnome wiki page again)

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Polarity · 2019-10-02 20:38:57

Alright! Thanks again for your help! This really solved a long standing issue for me and I learned a lot! (will mark as solved now)

Polarity · 2021-07-26 08:53:57

Just adding the final solution in here after contacting VC support.

By default the UI is sent to display :0 but there is an environment variable to set it manually.

OPTICAL_FLARES_DISPLAY_NAME=:1

fastabst · 2022-01-25 12:25:08

Polarity wrote:

Just adding the final solution in here after contacting VC support.
By default the UI is sent to display :0 but there is an environment variable to set it manually.
OPTICAL_FLARES_DISPLAY_NAME=:1

Hi everyone, I have the same issue, but couln't solve it, you just are too advance and amazing! Where should I add like OPTICAL_FLARES_DISPLAY_NAME=:1 ? I've tried to follow .xinitrc approach, but couln't work it work yet.

Many thanks!

Polarity · 2022-01-25 21:54:58

Hi fastabst,
You have two options to do this:

[1] You can either set it as an environment variable: see this.

[2] You can edit Nuke's .desktop file, so it will be set every time you launch it. The (e.g.) file 'Nuke13.1.desktop' is usually in /usr/share/applications/. - Then insert the following in the exec= line:

env OPTICAL_FLARES_DISPLAY_NAME=:1

So the entire line would look like so:

Exec=env OPTICAL_FLARES_DISPLAY_NAME=:1 "/usr/local/Nuke13.1v2/Nuke13.1" -b  %f

While [2] is certainly easier, doing [1] has the advantage, that the variable will always available, even if you launch Nuke from command line. [2] only works when you launch Nuke via the launcher in your dock/dash/overview/app menu/... .

Some tips on the side: You can use the same method to set OPTICAL_FLARES_PRESET_PATH, OPTICAL_FLARES_LICENSE_PATH, foundry_LICENSE (this is good to avoid them creating a folder in the user home directory), etc.

Hope this helps!

Arch Linux

#1 2019-10-01 14:59:58

[SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#2 2019-10-01 17:44:40

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#3 2019-10-01 18:01:30

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#4 2019-10-01 18:50:06

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#5 2019-10-01 20:39:17

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#6 2019-10-02 08:06:35

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#7 2019-10-02 12:36:44

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#8 2019-10-02 12:57:50

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#9 2019-10-02 13:55:52

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#10 2019-10-02 17:15:50

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#11 2019-10-02 19:24:32

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#12 2019-10-02 20:01:45

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#13 2019-10-02 20:20:08

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#14 2019-10-02 20:38:57

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#15 2021-07-26 08:53:57

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#16 2022-01-25 12:25:08

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

#17 2022-01-25 21:54:58

Re: [SOLVED] Plugin UI Window does not open: Invalid MIT-MAGIC-COOKIE-1

Board footer