GLOBUS-PERSONAL-GA(1)

GLOBUS-PERSONAL-GA(1) — okay bestie, this is the man page for globus-personal-gatekeeper, and it lives in the Grid Community Toolkit Manual. Grab a strawberry 🍓, we're going in.

✨ NAME ✨

globus-personal-gatekeeper — the command that manages your very own personal gatekeeper daemon. Not the system one. Yours. Main character energy, honestly. 👑

🌸 SYNOPSIS 🌸

globus-personal-gatekeeper [-help ] [-usage ] [-version ] [-versions ]
[-list ] [-directory CONTACT]

💅 DESCRIPTION 💅

So globus-personal-gatekeeper is this lil utility that manages a gatekeeper and job manager service for a single user — that's you, babe. Depending on what you pass on the command line, it snaps into one of several modes, and it's giving three distinct vibes:

1. The first set of arguments up in the synopsis? That's the "just tell me stuff" mode — info about the globus-personal-gatekeeper command itself, or about the instances of globus-personal-gatekeeper that are running right now.
2. The second set? That's your control panel for starting a brand new globus-personal-gatekeeper instance.
3. The final set? That's how you terminate one or more globus-personal-gatekeeper instances. Bye bye. 💀

The -start mode will create a new subdirectory of $HOME/.globus and write the configuration files needed to start a globus-gatekeeper daemon, which will invoke the globus-job-manager service when new authenticated connections are made to its service port. Then globus-personal-gatekeeper dips — it exits, printing the contact string for the new gatekeeper to standard output, prefixed by GRAM contact:. Obsessed with a clean exit. 🫶

Also, on top of the arguments listed above, literally any argument described in globus-job-manager(8) can be appended to the command line, and it'll get added to the job manager configuration for the service that the globus-gatekeeper started. Slay.

The new globus-gatekeeper keeps running in the background until you kill it by invoking globus-personal-gatekeeper with the -kill or -killall argument. When it gets killed, it kills the globus-gatekeeper and globus-job-manager processes, removes state files and configuration data, and then exits.

Heads up bestie, this part matters 😭 — jobs that are running when the personal gatekeeper is killed will continue to run, but their job directory will be destroyed, so they may fail in the LRM. Not a vibe. Know that before you pull the trigger.

The full set of command-line options to globus-personal-gatekeeper consists of:

• -help, -usage — prints the command-line option summary and exits. That's it, that's the whole thing. 🙈
• -version — prints the software version.
• -versions — prints the software version, but make it extra: this one includes DiRT information. ✨
• -list — prints a list of all currently running personal gatekeepers. These entries will be printed one per line.
• -directory CONTACT — prints the configuration directory for the personal gatekeeper with the contact string CONTACT.
• -debug — prints additional debugging information when starting a personal gatekeeper. This option is ignored in other modes, so don't come for it in -list mode. 🙅
• -start — starts a new personal gatekeeper process. Iconic.
• -jmtype LRM — use LRM as the local resource manager interface. If you don't provide it when starting a personal gatekeeper, the job manager will use the default fork LRM.
• -auditdir AUDIT_DIRECTORY — write audit report files to AUDIT_DIRECTORY. If you don't provide it, the job manager will not write any audit files.
• -port PORT — listen for gatekeeper TCP/IP connections on the port PORT. If you don't provide it, the gatekeeper will let the operating system choose. Letting the OS decide is lowkey iconic of it.
• -log[=DIRECTORY] — write job manager log files to DIRECTORY. If DIRECTORY is omitted, the default of $HOME will be used. If this option is not present, the job manager will not write any log files.
• -seg — try to use the SEG mechanism to receive job state change information, instead of polling for these. These require either the system administrator or the user to run an instance of the globus-job-manager-event-generator program for the LRM specified by the -jmtype option.
• -acctfile ACCOUNTING_FILE — write gatekeeper accounting entries to ACCOUNTING_FILE. If you don't provide it, no accounting records are written.

🦋 EXAMPLES 🦋

Okay so here's the output when you start a new personal gatekeeper that schedules jobs via the lsf LRM, with debugging enabled:

% globus-personal-gatekeeper -start -jmtype lsf

verifying setup...
done.
GRAM contact: personal-grid.example.org:57846:/DC=org/DC=example/CN=Joe User

And here's what it looks like when you list the current active personal gatekeepers:

%  globus-personal-gatekeeper -list
personal-grid.example.org:57846:/DC=org/DC=example/CN=Joe User

And here's what you get when you query the configuration directory for the above personal gatekeeper:

%  globus-personal-gatekeeper -directory "personal-grid.example.org:57846:/DC=org/DC=example/CN=Joe User"
/home/juser/.globus/.personal-gatekeeper.personal-grid.example.org.1337

%  globus-personal-gatekeeper -kill "personal-grid.example.org:57846:/DC=org/DC=example/CN=Joe User"
killing gatekeeper: "personal-grid.example.org:57846:/DC=org/DC=example/CN=Joe User"

🌈 SEE ALSO 🌈

globusrun(1), globus-job-manager(8), globus-gatekeeper(8) — go read those next, they're the friend group. 🫶

👑 AUTHOR 👑

Copyright © 1999-2016 University of Chicago

And that's the whole page, babe. This one came from the Grid Community Toolkit, version 6, dated 03/31/2018. You understood the assignment. Periodt. 💜🌸✨