Margaret,
On out two Linux based spectrometers we are measuring the time users are
running Topspin by using a modified version of Frits Abildgaards (UW Madison)
script. It runs as a cron job every five minutes to check who
is logged in and whether they are running Topspin. The output is logged
in a file and and converted monthly into an accounting summary by a Perl
script from the same source.
This setup works well for us, regardless whether the user uses Topspin or
ICONNMR to acquire their data. Conceivably a really fast user could stay
under the radar by running their sample in much less than five
minutes, butt I have not seen that this is an issue for us, one could
easily run the script every two or one minute. As to the issue of users
logging out with an acquisition running, one could modify such a script
to include those cases, by looking up the last Topspin user in the logs,
then checking the <Topspin>/prog/curdir/,User>/shmem file for ongoing
acquisitions, or simply checking for any instances of Topspin running
for that user.
I am not sure how big of an issue users logging out with acquisitions
running is, from my attempts Topspin running in the background seems to
lock spectrometer access the next time I try to run Topspin, and I need
to manually kill the Topspin processes from the command line. So unless
the students in question are Linux pros I would expect users coming to
you saying that they cant open Topspin. So maybe the suggestion of
killing remaining Topspin processes in a post session script is a better
solution.
Holger
On 8/25/2025 6:04 PM, Eastman, Margaret via groups.io wrote:
> Dear AMMRL:
>
> We charge for NMR time according to login time on the spectrometer
> computer for our manually operated spectrometers. They all run Linux
> and my accounting program reads the “last” files to find the login
> times. I have done this for many years without an issue being made of
> it, but now there is concern that users may be gaming the accounting
> system by logging in, starting an experiment, logging out, then maybe
> just logging back in later after the experiment is done to remove the
> sample, thus having one or two short logins instead of one login that
> includes the entire acquisition.
>
> I know that some facilities just use acquisition time from the Bruker
> “account” information, but on principle I do not want to do that,
> since that fails to charge for actual time occupied on the instrument
> which will always exceed acquisition time, sometimes substantially.
>
> I’m tasked with fixing this vulnerability.
>
> One option is to find a way to prevent users from running data
> collection while they are not logged into the spectrometer computer. I
> have no idea how to do this. Has anyone done this, particularly for a
> Bruker spectrometer? The only thing I can think of is possibly to have
> the OS detect a process and kill it, maybe the TopSpin process, but
> that would be very unceremonious and maybe not safe.
>
> A second option is to take the Bruker “account” files for each
> individual day in the month and write additional code for my
> accounting program to read and interpret these and use them to correct
> the accounting in case of discrepancies, which would be cases when
> acquisition time exceeded login time.I might be able to do this, but
> do not want to be required to go in each month, on each spectrometer,
> and use the Bruker “account” command many times to separately bring up
> and save about 30 files one for each day then combine them into
> single input file for the program. This is kind of maddening manual
> work. Does anyone have a script that can be typed on the TopSpin
> command line to get the account data for every individual day in a
> month written out as one file? Or any advice on writing such a script?
> ( Also, now that I think more about it, I’m not sure how these
> “account” files deal with acquisitions of more than one day and if
> policing longer acquisitions requires every possible multiple-day
> “account” file for the month.)
>
> Does anyone have another way to get around this problem? Must admit
> I’m not keen on throwing my accounting program out the window, as it
> has worked well for many years and provides yearly as well as monthly
> reports.
>
> Please help.
>
> Margaret
>
--
Frank H. Foersterling
Instrumentation Specialist
CHM B-10
Department of Chemistry
University of Wisconsin-Milwaukee
414-229-5896(Lab) 414-229-5035 (Teams)
holger_at_uwm.edu
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#2754): https://urldefense.com/v3/__https://ammrl.groups=
.io/g/main/message/2754__;!!PvDODwlR4mBZyAb0!Sxe9rcRhvcnu2V66AdnJ6IgeeHky30=
cK-BFwWXiGY3IZkYmU3yZou1_ArmpiMzO7dlk-BK0jUKECPCtW5NrJYM_Q2Q$
Mute This Topic: https://urldefense.com/v3/__https://groups.io/mt/114891633=
/7559972__;!!PvDODwlR4mBZyAb0!Sxe9rcRhvcnu2V66AdnJ6IgeeHky30cK-BFwWXiGY3IZk=
YmU3yZou1_ArmpiMzO7dlk-BK0jUKECPCtW5Np-FHwa6Q$
Group Owner: main+owner_at_ammrl.groups.io
-=-=-=-=-=-=-=-=-=-=-=-
Received on Tue Aug 26 2025 - 10:00:05 MST