Is there a standard command to check which users are working out of your flame? I’ve worked at facilities where you can use flame -users and it’ll return a list of who is working on your flame but it seems to be a bespoke command.
1 Like
Do you mean who is actively using flame? Or just who is logged into the machine?
1 Like
Yeah, who is actively using your machine, ie logged into and working on another project on your flame.
just type w in a terminal window. It should list the user and the ip address, but I think the user is just the version of flame, unless you have a setup in which the artists log in with their own credentials before starting Flame. In which case this is what you seek. If not, you should be able to track down the terminal they are using, but I’m not sure that’s what you really want. I think what you are looking for is active flame user. In which case you can navigate to /opt/Autodesk/users/ and open up the user.db file and read the line UserGroupStatus:UsrGroup1=<current_user_name_is_here>. DON’T modify the file. There may be an easier way someone else might know, but this will get you there.
2 Likes
Thanks, that w command is handy but I’m not sure it does what I’m after. It’s handy to know who’s remoting into your flame - both to diagnose general slowness but also to know if you’re going to screw someone over if you reboot.
Run vic in a shell. It should be in your path, but if it’s not, then it’s
/opt/Autodesk/io/bin/vic -v stonefsWhateverYourStoneis
(ours are stonefs7)
If it runs, no one is conneted. If there are other flame connected, it will error and tell you which machines by name.
1 Like
You can run vic with -C to just see the volume connections so you don’t have to bother running through the actual vic if nobody is connected.
That will still only give you the PID and host of the other Flame though. I think in order to know who the user is it would be most efficient to parse the output of vic into a command that would ssh onto the remote host and run a ps to determine the owner. That seems like a rather annoying exercise though.
I don’t think you can reliably get the user from the user.db since UserGroupStatus:UsrGroup1=<user> only returns the most recent user from what I can tell and it may not update at all if the remote user is pulling a profile from their localhost.
However, you can see which user profiles are in use by going to /opt/Autodesk/user/<user>/tmp/ . If you list that out then you can see the host and PID with a lock on the user. Compared with the output of vic you could pretty quickly determine which Flame user is remoting into your flame.
Without scripting it up I think the fastest way is to run
/opt/Autodesk/io/bin/vic -a -C
Look for any connections from Flames that aren’t your own. Note that this list can contain “ghost” connections where a Flame was previously connected but the volume lock was not cleaned after the session was closed.
Then run
ls -l /hosts/*/opt/Autodesk/user/*/tmp/*
The output of that command will show you which Flame users are currently locked and by which host and PID. If you scan through that list you may be able to match up the host and PID from vic with one from the ls command. Note that user-locks are even less reliably deleted than volume locks. I’m looking at list of user-locks right now that has entries dating back to April of last year. Also in theory scanning /hosts should capture all of the Flames which might be connected to yours, but in practice I’m not sure thats true.
Anyway thats the best I can think of. Would love to see a more elegant solution if there’s one out there.
2 Likes
top is probably the easiest command to tell you if flame is actually running. It’s always on top.
Thanks - that does the trick. In reality I just needed to know if another flame is connected, the specific user isn’t massively important (I phrased my intitial question badly, apologies). The facility I work where they have a bespoke command only tells you what flame is connected, not user - and they have some quite clever coders. It’s generally easiest to correlate a user by talking to bookings!
Cheers. It was an interesting problem to think about. Ideally something like this would be built into Flame. Kind of crazy that it doesn’t exist when you think about it.
Everything is there under the hood, but there isn’t a great way to see it. You can kind of see it when you try to load up a project and user that are being used by someone else. It’ll spit out all the relevant information about who’s got what open from where into the shell. Just not a particularly efficient way of going about discovering who is on your Flame.
Yeah, really crazy there isn’t a proper tool for doing this built into the UI - particularly when you consider how flames are mostly used in facilities.
Central Stone+Wire for the win here. I really can not stress enough how much of a benefit this is in a multi-flame environment.
3 Likes