GLOBUS-SCHEDULER-E(8)

πŸ’– GLOBUS-SCHEDULER-E(8) πŸ’–

okay bestie, welcome to the manual page for globus-scheduler-event-generator β€” it lives in the Grid Community Toolkit Manual and honestly? it's giving backstage-pass energy for your cluster. πŸŽ€


✨ NAME ✨

globus-scheduler-event-generator β€” literally just here to process job state change events πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

globus-scheduler-event-generator -h

globus-scheduler-event-generator -s LRM_NAME [OPTIONS]

🌸 DESCRIPTION 🌸

so. the globus-scheduler-event-generator (aka SEG, because we're on nickname terms now) is a program that uses local resource manager-specific monitoring modules to generate job state change events. 🫢 At the SEG level, those state change events correspond to changes in any jobs which are managed by the scheduler β€” even if they do not correspond to jobs initiated by the GRAM5 Service. and then those state change events get propagated to the Job State Monitor. iconic behavior, no cap.

depending on scheduler-specific requirements, the SEG may need to run with privileges so it can actually obtain scheduler event notifications. because of that, one SEG runs per scheduler resource. for example, on a host which provides access to both PBS and fork jobs, you'd have two SEGs running, at (potentially) different privilege levels. two of them. living their separate lives. πŸ’€

when executed, the SEG is able to start issuing events from some time in the past. and the SEG will, in general, not require any persistent state between invocations β€” it's not clingy, it doesn't need to remember anything. one SEG instance exists for any particular scheduled resource instance (one for all homogeneous PBS queues, one for all fork jobs, etc). periodt.

the SEG is implemented in an executable called the globus-scheduler-event-generator, located in the Grid Community Toolkit's sbin directory. πŸ“

when begun, it loads the LRM-specific module based on the LRM_NAME parameter, and then defers to it for most functionality. and when it detects an error writing to stdout or reading stdin, it terminates. that's it, it's done, it's leaving the group chat. 😭 the LRM-specific code uses the SEG API to emit events to the GRAM5 service.


πŸ‘‘ OPTIONS πŸ‘‘

  • -h β€” Display a help message and exit. your little "hey what do I do" button, bestie, use it freely.
  • -s LRM_NAME β€” Load the LRM-specific module for LRM_NAME. This is translated to loading the dynamic library libglobus_seg_’LRM_NAME'. yes, that's the actual name, don't come for me.
  • -t TIMESTAMP β€” Process events starting at TIMESTAMP. this is the only way to get the globus-scheduler-event-generator to process events that occur before the process begins. if you don't specify it, it will generate events from the current timestamp only β€” so no time traveling unless you ask. ⏰
  • -d DIRECTORY β€” Write job state change events to files in DIRECTORY, named by the day that the event occurred (DIRECTORY/YYYYMMDD). if not specified, the events will be written to standard output. choose your adventure. πŸ“
  • -b β€” Run in the background. ⚠️ this only works if the -d option above is used. no -d, no backgrounding, that's the rule.
  • -p PIDFILE β€” Write the process id of the globus-scheduler-event-generator to PIDFILE. so you can find it later. tracking your faves. πŸ”₯

πŸ’œ AUTHOR πŸ’œ

Copyright (c) 1999-2014 University of Chicago


and that's the whole page, bestie!! 🧚✨ this was Grid Community Toolkit 6, dated 03/31/2018 β€” go forth and generate those events, you absolute main character. πŸ’–πŸŒˆβ­