/ MIT-MAGIC-COOKIE / chpasswd problem

This afternoon, apropos of nothing obvious, my screen jumped from whatever I was looking at (probably Emacs, Konsole or a web browser) to the screen lock screen, except a little faded. It stopped recognizing keystrokes.

I later discovered that the power was extremely low. The power cable had disconnected. (Sometimes my machine has problems with power settings. For a while a few weeks ago they were grayed out under KDE’s Settings menu, but now they seem fine.)

I rebooted, and now it recognizes keystrokes, but if I try to log in as my normal user (“jeff”) it flashes some text too fast to read and then returns me to the login screen. I took a video of that process. For some reason VLC doesn’t work when I’m root so I can’t look at it.

I can still log in as root, so I modified my configuration to create another user called “j2”. That seems to rebuild fine, except that it complains about an MIT-MAGIC-COOKIE problem:

[root@jbb-hp17:/home]# sudo nixos-rebuild switch
building Nix...
building the system configuration...
activating the configuration...
warning: not applying UID change of user ‘jeff’ (1000 -> 999)
setting up /etc...
reloading user units for root...
reloading user units for jeff...
Invalid MIT-MAGIC-COOKIE-1 keyxset:  unable to open display ":0"
setting up tmpfiles

After that, when I run chpasswd j2, it hangs until I press Ctrl-C:

[root@jbb-hp17:/home/jeff]# chpasswd j2

Sounds like your laptop didn’t shut down, but switched to a different tty while going to sleep, so the other display is still open, except unlock is a little broken for some reason? Have you tried rebooting by hand since? Alternatively it could also be a leftover display “cookie” file in your home directory that needs deleting or such.

Can you sign in as your user from another tty using ctrl-alt-F4 (or any other F key)?

Can you share the contents of journalctl and dmesg?

I’d wager chpasswd is hanging because your DISPLAY is set to :0 where polkit is asking you to type your password, but you can’t see it because it’s on another tty. You can try running unset DISPLAY before chpasswd.

As an aside, VLC (and many other user-facing applications) will refuse to run if you’re root. This is because root should never be signed into a graphical session, and most certainly not use any normal desktop applications. You have permission to break your system in many ways, with no prompts, as the root user, and GUI applications do enough things that there is a somewhat legitimate risk in using them. So a lot of them simply refuse to start when you’re root.

If you need to do administrative work as the root user to recover from situations like this, switch to a different tty with the ctrl-alt-Fx combo, and sign in as root there (but prefer to sign into your account if possible). This also prevents problems like your hanging chpasswd.

Thanks, @TLATER!


I’ve rebooted a few times, by holding down the button and by telling KDE normally.

find a stale cookie in home folder

From /home/jeff, running find . -iname "*magic*cookie*" finds nothing. Searching instead for *cookie* returns (excluding obvious non-candidates in folders I created by hand) the following:

./.config/google-chrome/Default/Extension Cookies-journal
./.config/google-chrome/Default/Safe Browsing Cookies-journal
./.config/google-chrome/Default/Extension Cookies
./.config/google-chrome/Default/Safe Browsing Cookies
./.config/BraveSoftware/Brave-Browser/Default/Extension Cookies-journal
./.config/BraveSoftware/Brave-Browser/Default/Safe Browsing Cookies-journal
./.config/BraveSoftware/Brave-Browser/Default/Extension Cookies
./.config/BraveSoftware/Brave-Browser/Default/Safe Browsing Cookies
./.config/BraveSoftware/Brave-Browser/Guest Profile/Safe Browsing Cookies-journal
./.config/BraveSoftware/Brave-Browser/Guest Profile/Safe Browsing Cookies

login as normal user from another terminal

I can! After entering my password it says

xset: unable to open display ""

but then it drops me into a shell. I can even run Emacs! (Although it’s pretty hard to read; I only know how to double the font size with setfont -d and that’s still pretty small for my eyes.)

From another GUI-less terminal I tried logging in as root to see if chpasswd would work from there, but still it seems to hang. However, it still lets me type, and letters (not asterisks) appear on the screen when I do. Then, when I press enter, it reports “chpasswd: line 1: missing new passwd”. If I try again it reports, “chpasswd: line 1: missing new passwd”. It continues like that until I press Ctrl-C.

dmesg and journalctl

I can’t seem to access Github as root so I’ve put those on my Google Drive:


The journalctl file is 302 MB.


In KDE as root, unset DISPLAY seems to have had no effect:

[root@jbb-hp17:~/Downloads]# unset DISPLAY

[root@jbb-hp17:~/Downloads]# chpasswd j2


The file is called ~/.Xauthority (make sure you delete the user’s Xauthority, not root’s), but I wanted to see the logs before I implicate it. Who knows though, deleting it can only hurt while your desktop is running :slight_smile:

Your logs don’t show any errors worth mentioning from what I can see without too much digging. Looks like everything is running fine, but I suspect I’m not looking at you trying to log in.

journalctl -xe --boot will give you just the logs from the current boot, and gives some helpful additional information about when services start and stop. For my sanity, I’d love it if you could just boot your computer, try (and fail) to sign in once, switch to a tty, dump that command to a file and then share it.

Something like pastebin, hastebin or ghostbin are nicer ways to share these files than google drive as well, or if you can spot where the login failure happens just put exactly that part of the file with some of the surrounding context here, using a code block.

It’s possible your X logs are not in the journal. They sometimes end up in /var/log/X11 or ~/.xsession-errors, too, depending on your configuration.

I’ll admit, I’ve never used chpasswd before, but from a cursory glance at the man page it seemed like it takes a bunch of lines from stdin and then uses them to change the password of a whole batch of accounts. So I figure your “hanging” is actually “waiting for input”.

I figured you knew how to use it, are you sure you’re not looking for the similarly-named passwd command? To my knowledge it won’t show asterisks either, though, you just need to blind type the password twice.

Thanks again, @TLATER!

journalctl -xe --boot after failed login and (almost) nothing else

I tried and failed to login to X as my borked user “jeff”, switched to a TTY, and did almost nothing but run journalctl -xe --boot > journalctl.txt. I may have run pwd, ls, and one or two other minor commands; I can’t remember if I did that before or after writing the file. Sorry about that.

I put the result on pastebin like you suggested. I named the paste wrong – it should say journalctl where it says dmesg.

How can I learn whatever it is that you know that allows you to read that output?

chpasswd v. passwd

You’re right! I meant passwd, which in fact works. And that allowed me to login to the new j2 user, where everything seemed to be as it should be.

I solved it, inelegantly.

First, as root, I tried hiding the maybe-problematic cookie, by moving it from /home/jeff/.Xauthority to /home/jeff/.Xauthority-bk/.Xauthority. I still couldn’t log in as my original jeff user.

So then, as either root a new user (can’t remember), I rebuilt my config to exclude the old jeff user, renamed the old /home/jeff/ folder, rebuilt my config to again include a jeff user, and then moved data from the old, renamed home folder to the new /home/jeff.

The first time I tried that, I retained every single file, and the problem reappeared. So the second time, I left behind .cache, .config and .local.

A brutish solution, but it seems to work so far.