Dear All:
Sorry! A few of you pointed out, and my own tests now confirm that the issue
I brought up is invalid: It is not possible for an acquisition to continue
after a user is logged out from the spectrometer computer on a Bruker
spectrometer running TopSpin. Exiting TopSpin of course requires the acquisition
to be terminated, and if the user does not exit from TopSpin the acquisition
stops upon log out.
A few of us have seen odd rogue TopSpin processes running after logout and
John Decatur’s script should eliminate them. If they arise (which is
probably more likely) from someone using switch user instead of logging out,
disabling switch user for all logins should prevent that problem. I’ve
found a method to disable switch user for all logins in Alma 9.
Margaret
> From: main_at_ammrl.groups.io on behalf of Eastman, Margaret via groups.io
> Date: Tuesday, August 26, 2025 at 12:00 PM
> To: main_at_ammrl.groups.io
> Subject: Re: [AMMRL] AMMRL: Accounting by computer login - How to prohibit gaming the system
Dear All:
Thanks for this info. In thinking more about this, I realized that I do not
want to use the Bruker accounting files to clean up after the problem happens,
but rather I need a preventative solution like the one John Decatur describes,
having the OS detect at logout time if TopSpin is still running and killing
it if it is. And I was thinking maybe the user is presented with a message
requiring that they stop the acquisition and exit TopSpin before they can log
out. Then they either must get out of TopSpin, stopping the acquisition, or
not log out to continue the acquisition in the case they were trying to cheat
my accounting method. This should also fix a problem we have encountered of
users (who are not running an acquisition) not exiting from TopSpin, after
which other users cannot run TopSpin because the license is tied up.
Margaret
> From: main_at_ammrl.groups.io on behalf of John Decatur via groups.io
> Date: Tuesday, August 26, 2025 at 9:40 AM
> To: main_at_ammrl.groups.io
> Subject: Re: [AMMRL] AMMRL: Accounting by computer login - How to prohibit gaming the system
Hi All,
I basically duplicate the info given by the last command by having scripts
in the /etc/dgm/PreSession and /etc/dgmPostSession directories. These are
executed upon login and logout. The PreSession script logs the user info
into a file while the PostSession script checks for Topspin and, if running,
kills it prior to logging output data and then executing the logout. i
then have an ancient Perl script that processes the info in this monthly
stored file. You could customize what these scripts generate to fit with
your existing processing programs.
I tell my users if they logout then their experiment stops (which is true!)
and thus I have no one attempting to circumvent paying by logging out. I have
never noticed an issue generated by killing Topspin in this way (although almost
all users exit Topspin prior to logging out).
I notice mismatched pairs occasionally in this log file (one or two a month but
those are easily cleaned up and removed. My guess is that these are the result
of a user that has, instead of logging out, either powered down the computer or
reboot it but I’ve never bothered to track down the precise cause.
Happy to share to those in need.
John
On Aug 26, 2025, at 9:05 AM, gregory.wylie via groups.io wrote:
Hi Everyone
We have noticed that when using the Bruker accounting file we miss time, and
have started comparing our accounting with the reservation system we use. We
are also going to start using last files as well to see how things turn out
that way too. I was able to replicate some of the missing time issues we were
seeing with the Bruker accounting file. A couple things we found that cause
us problems:
1. Double starting the software
2. If the user started the software from terminal and then closes the terminal.
3. Not waiting for the software to fully close before logging out of the computer.
Most often these result in miss matched line pairs in the Bruker accounting
file so our current scripts throw them out. This has resulted in a potential
lose of ~1500 hours of billable time on 1 machine over a year. We only have
1 Bruker that runs manually all others are in IconNMR and we have not seen
any issues on these systems.
We do think using last will work better as we currently use last to compare
with the reservation system to look for users who may be abusing the rules
of usage. We do this twice a month and send out emails to offenders to be
better. We don't think users are doing anything intentionally because if we
find too many issues in a month we will ban the user from the system!
Very interested to see what others are doing as well.
Greg
Gregory P. Wylie, Ph.D
NMR Facility Manager
Texas A&M University
Department of Chemistry #3255
580 Ross St.
College Station, TX 77843-3255
gpwylie_at_tamu.edu<mailto:gpwylie_at_tamu.edu>
979.458.0705 (voice)
979.845.4719 (fax)
706.206.0007 (cell)
http://nmr.tamu.edu
John Decatur, Ph. D.
Senior Research Scientist, Director of Chemical Instrumentation
and Precision Biomolecular Characterization Facility
Department of Chemistry
3000 Broadway, Mailcode 3179
Columbia University
New York, NY 10027
212-854-2155 (voice)
212-932-1289 (fax)
jdd13_at_columbia.edu
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#2756): https://urldefense.com/v3/__https://ammrl.groups=
.io/g/main/message/2756__;!!PvDODwlR4mBZyAb0!WMaeEnTHms4x737fpGd494w6P_x6oC=
UN1wRiTHceHbujCqadDkGFGJ3j5rmH4aIi7iz42mBRaso7m9jOC6NKZulEpHOj$
Mute This Topic: https://urldefense.com/v3/__https://groups.io/mt/114891633=
/7559972__;!!PvDODwlR4mBZyAb0!WMaeEnTHms4x737fpGd494w6P_x6oCUN1wRiTHceHbujC=
qadDkGFGJ3j5rmH4aIi7iz42mBRaso7m9jOC6NKZsfRB7HW$
Group Owner: main+owner_at_ammrl.groups.io
-=-=-=-=-=-=-=-=-=-=-=-
Received on Wed Aug 27 2025 - 15:45:01 MST