2025: "Session expired"

Since installing 2025.1 Linux, I’ve had several times when I come back to the box and Flame is hung up. The Firefox browser says “Session Expired”. Flame fails to relaunch. Then I have to reboot. Anyone else seeing this??

Also when logging in, each time I get a browser pop up “Unable to access information in your keyring.” What is that about?

I think Linux caught up what we had on the Mac for a while. The browser session expired is harmless. I get that on the Mac all the time. Just a leftover from the browser based sign-in.

I haven’t seen it hung hung. But there are occasions where it can take a minute before it relaunches. How long are you giving it before you reboot?

On the Mac in a few occasions it has helped to kill the ADSK license processes. Forget what their names are, but pretty obvious. I think sometimes the freeze up.

That browser based sign in is a good idea in principle, but there are some definite gremlins left over.

Something in the licensing components of 2025.1 changed significantly and completely broke in our infrastructure. I had a long Zoom with ADSK MTL and Singapore last week regarding the issue, and they were stumped. The only way we are able to run ANY version of Flame, is to un-install all ADSK Licensing components from 2025.1 and install the ones from 2025.

1 Like

This session expiring thing is a potential show stopper in my opinion. How can I know that my overnight renders, or my project archive, will actually happen, or if Flame will just hang?

There are a handful of reasons that I wish I’d stayed on 2024.

1 Like

Exactly Alan, I’ve found the way to stop this issue is having previous installations, 2024.1.1, logged in and saved the login credentials and then you can go up. If I go clean and install 2025.1 then I’ll face same issue Greg-Paul and many people is facing. So, install latest 2024.x.x, login, then install 2025.1. You can even install just the licensing app and not the whole flame package.

Its a bit annoying having to install two flames on system to avoid this but it is way to shield yourself.

I dont think Flame will hang in the middle of any process, it just wont launch next time you run the app.

1 Like

@GPM - flame archiving can be achieved without the flame gui, so that’s one problem off the table.

if you want I’d be delighted to help you with an example script, and show you how to write your own.

if you have an old workstation lying around you can create a burn node and send your overnight jobs to burn.

flame does not need to be running for burn.

1 Like

I’m not sure if it is related but, our licensing got broken as well. We’re supposed to have 2 seats of single user license. My Linux box works as it is the main workhorse. But the mac demands to start Autodesk Identity Manager app which is a hell to find as a download, install with security clearence and then refuses to launch.

See screenshots - this is what I get on the Mac after I use browser based sign-in. 15 min later (or thereabouts) the browser tab changes to ‘session expired’. This is simply the login timeout of that browser authentication logic. It should not have direct bearing on your Flame sessions, as Flame doesn’t interact with the browser after start.

I can have Flame open the entire day with the browser saying ‘session expired’. In fact I usually close this tab to stop annoying me and it has no impact.

From what I can tell, that is the browser session, it is no reflection of your login session of the background licensing daemons running on Mac or Linux.


These are the licensing components running on the Mac (presumably with similar counter parts on Linux). On rare occasions I had to kill them. They will auto-start on the next sign-in.

Usually that happens when Flame exits abnormally for some reason (I had a a few hangs for unrelated bugs). These daemons may not realize that Flame has crashed. Most of the time it just takes 1+ minutes for Flame to restart, so I’m patient most of the time. But at times killing these resets things and avoids a reboot.

Screenshot 2024-09-05 at 8.31.00 AM

This is the Linux equivalent on Rocky 8.7 / Flame 2025 (not .1)

Next time you have an issue, instead of rebooting, try killing that process and see if it unlocks things.

All that said, the inability of ADSK’s licensing team to have a good handle on the Linux platform is not very re-assuring. It took forever to find out about the expired SSL certs, and only with significant prodding and helping. Now this new set of issues with 2025.1 They may have to add a Linux expert to their team.

I’d love to upgrade to 2025.1 on my Linux Flame to take advantage of the Inference node and MLTW. But this gives me pause. I don’t have time right now to deal with a big software issue. May way until the holidays when things slow down.

This is not particularly helpful but I’ve been running 2025.1 for weeks and haven’t seen or had any of these issues. So there might be something pertinent to your system setups causing this?

We’re running Rocky 8.7 on P620s.

1 Like

@AdamArcher Good to know. I wonder if there’s a difference between 8.7 vs. 9.3 - @cristhiancordoba and @ALan which version of Rocky are you on?

As I documented at length a few months ago, 9.3 had a rocky start for me, so I stayed on 8.7 in the end. While the official testing with 9.3 found not issues, I think there are a few gremlins in the detail.

Probably depends on the type of license. They are quite convoluted. We just got a quote for:

Product SKU Name : C0TN1-006379-L308 Flame Commercial Product Subscription Renewal Single-user Annual Multi-user 2:1 Trade-in Non - Specific Worldwide Linux.Macintosh

I hope this gives me two concurrent users, one on Linux one on Mac.

Out of interest, are you all using Firefox for web browsing on your systems? None of us are here, we use either Chrome or Edge. I just wonder if once Firefox has stored a password in the keychain then that might stuff something up with Flame licensing?!! Another long shot would be to remove all Firefox cookies.

We’re also using AD users. Just wondering since user settings have moved to OS users if something similar is happening for licensing as well?

1 Like

As in the Flame user and licensing being tied to the OS user. I could see how the keychain could be affected by that as it is linked to the OS user too.

On Linux I think Firefox is the default and I left it at that, but also use Chrome. Though Flame login will run through whatever is set as the default browser.

On Mac I use Brave as my default browser, which is based on Chromium.

I try to avoid Chrome except for Google services and anything that can’t run in the others.

I don’t use Keychain and no AD.

@AdamArcher Are you using 2025.1 on a clean linux install or you had previous version that you uninstalled and then installed 2025.1?

In my case I’m on linux using Chrome for everything, I dont use Firefox at all.

I’m on RL 8.7, dont even bother to try 9.3 while seen all these folks struggling with it. Nah!

1 Like

We are on RL 8.7 currently. Teradici wasn’t playing nice with RL 9.3 last I tried which is was maybe 2 months ago. Also Switchligh Studio doesn’t work on RL 9.3.

2 Likes

Switchlight didnt work for me on 8.7 either :frowning: :eyes:

Definitely does for me on RL 8.7. But I do think they have abandoned this software as it hasn’t been updated in a long time and I never got a response from their support address.

Likely what happened is the open source models became so good, they realized they can’t monetize this.