QPING(1)

🌸 NAME 🌸

qping — it's the Grid Engine vibe check bestie 💅 this is QPING(1) from the Grid Engine User Commands section, and what it does is check the application status of Grid Engine daemons. Yes, literally just poking the daemon and asking "u up? 🫶"

---

✨ SYNTAX ✨

okay so here's the whole shape of it, don't panic, we'll go through every single bit:

qping [-help] [-noalias] [-ssl|-tcp] [[[-i interval] [-info] [-f]] | [[
-dump_tag tag [param]] [-dump] [-nonewline]]] host port name id

---

🦋 DESCRIPTION 🦋

So qping is how you validate the runtime status of a Grid Engine service daemon. In the current Grid Engine implementation you can query the SGE_QMASTER daemon and any running SGE_EXECD daemon — that's the whole guest list 🎀

The way it works: the command sends a SIM (Status Information Message) to the destination daemon. The communication layer of that daemon then responds with a SIRM (Status Information Response Message) which has status information about that daemon inside it. cute, right? 💖

It also has options that let an administrator observe the communication protocol data flow of a Grid Engine service daemon. nosy but make it sysadmin ✨

---

👑 OPTIONS 👑

💜 -f

Show full status information on each ping interval. This is the deluxe version, here's everything it gives you:

• First output line: shows the date and time of the request.
• SIRM version: internal version number of the SIRM (Status Information Response Message).
• SIRM message id: current message id for this connection.
• start time: start time of daemon. The format is as follows:

MM/DD/YYYY HH:MM:SS (seconds since 01.01.1970)

• run time [s]: run time in seconds since start time.
• messages in read buffer: number of buffered messages in the communication read buffer. The messages are buffered for the application (daemon). When this number grows too large the daemon is not able to handle all messages sent to it.
• messages in write buffer: number of buffered messages in the communication write buffer. The messages are sent from the application (daemon) to the connected clients, but the communication layer wasn't able to send the messages yet. If this number grows too large, the communication layer isn't able to send them as fast as the application (daemon) wants the messages to be sent.
• number of connected clients: this is the number of clients actually connected to this daemon, including the current qping connection. hi bestie, you're in the count 🫶
• status: the status value of the daemon. This value depends on the application which replies to the qping request. If the application does not provide any information, the status is 99999. Here are the possible status information values for the Grid Engine daemons:

qmaster:

• 0 — there is no unusual timing situation.
• 1 — one or more threads has reached warning timeout. This may happen when at least one thread does not increment its time stamp for an usually long time. A possible reason for this is a high workload for this thread.
• 2 — one or more threads has reached error timeout. This may happen when at least one thread has not incremented its time stamp for longer than 10 minutes.
• 3 — the time measurement is not initialized.

execd:

• 0 — there is no unusual timing situation.
• 1 — dispatcher has reached warning timeout. This may happen when the dispatcher does not increment its time stamp for an unusually long time. A possible reason for this is a high workload.
• 2 — dispatcher has reached error timeout. This may happen when the dispatcher has not incremented its time stamp for longer than 10 minutes.
• 3 — the time measurement is not initialized.

• info: status message of the daemon. This value depends on the application which replies to the qping request. If the application does not provide any information the info message is "not available". Here are the possible status information values for the Grid Engine daemons:

qmaster:

The info message contains information about the qmaster threads, followed by a thread state and time information. Each time one of the known threads passes through its main loop the time information is updated. Since the qmaster has two message threads, every message thread updates the time. This means the timeout for the message thread (MT) can only occur when no message thread is active anymore:

THREAD_NAME: THREAD_STATE (THREAD_TIME)

THREAD_NAME:

• MAIN: Main thread
• signaler: Signal thread
• event_master: Event master thread
• timer: Timer thread
• worker: Worker thread
• listener: Listener thread
• scheduler: Scheduler thread
• jvm: Java thread

The thread names above (other than MAIN) will be followed by a 3 digit number.

THREAD_STATE:

• R: Running
• W: Warning
• E: Error

THREAD_TIME:

• Time since last timestamp updating.

After the dispatcher information comes an additional information string which describes the complete application status.

execd:

The info message contains information for the execd job dispatcher:

dispatcher: STATE (TIME)

STATE:

• R: Running
• W: Warning
• E: Error

TIME:

• Time since last timestamp updating.

After the thread information comes statistics on the malloc(3) state, if available, e.g. using mallinfo(3). If Grid Engine is built with the jemalloc(3) allocator, the statistics are not printed by default because they are in a different, verbose format. See print_malloc_info in sge_conf(5).

Monitor: if available (see MONITOR_TIME in qmaster_params in sge_conf(5)), displays statistics on threads. The data for each thread are displayed in one line. The format of this line can be changed at any time. Only the master implements monitoring.

---

🎀 -help

Prints a list of all options. that's it, that's the option ✨

---

⭐ -i interval

Set qping interval. The default interval is one second. Qping will send a SIM (Status Information Message) after each interval. so it's the "how often do we check in on them" dial 💌

---

🌈 -info

Show full status information (see -f for more information) and exit. The exit value 0 indicates no error. On errors qping returns with 1.

---

🧚 -noalias

Ignore host_aliases file, which is located at <sge_root>/<cell>/common/host_aliases. If this option is used it is not necessary to set any Grid Engine environment variable. freedom, kinda 💫

---

🔥 -ssl

This option can be used to specify an SSL (Secure Socket Layer) configuration. qping will use the configuration to connect to services running SSL. If the Grid Engine settings file is not sourced, you have to use the -noalias option to bypass the need for the SGE_ROOT environment variable. The following environment variables are used to specify your certificates:

• SSL_CA_CERT_FILE — CA certificate file
• SSL_CERT_FILE — certificates file
• SSL_KEY_FILE — key file
• SSL_RAND_FILE — rand file

---

💅 -tcp

This option is used to select TCP/IP as the protocol used to connect to other services.

---

🙈 -nonewline

Dump output will not have a linebreak within a message, and binary messages are not unpacked.

---

👑 -dump

This option allows an administrator to observe the communication protocol data flow of a Grid Engine service daemon. The command must be started as root, and on the host where the daemon to be observed is running.

okay so real talk: root + on the right host, both of those are requirements, not suggestions 💀

The output is written to stdout. The environment variable "SGE_QPING_OUTPUT_FORMAT" can be set to hide columns, set a default column width, or to set a hostname output format. The value of the environment variable can be set to any combination of the following specifiers separated by a space character:

• "h:X" -> hide column X
• "s:X" -> show column X
• "w:X:Y" -> set width of column X to Y
• "hn:X" -> set hostname output parameter X. X values are "long" or "short"

Run qping -help to see which columns are available.

---

🌸 -dump_tag tag [param]

This option has the same meaning as -dump, but can provide more information by specifying the debug level and message types qping should print:

• -dump_tag ALL debug level — this option shows all possible debug messages (APP+MSG) for the debug levels, ERROR, WARNING, INFO, DEBUG and DPRINTF. The contacted service must support this kind of debugging. This option is not currently implemented.
• -dump_tag APP debug level — this option shows only application debug messages for the debug levels, ERROR, WARNING, INFO, DEBUG and DPRINTF. The contacted service must support this kind of debugging. This option is not currently implemented.
• -dump_tag MSG — this option has the same behavior as the -dump option.

---

🍓 host

Host where daemon is running.

💖 port

Port which daemon has bound (used sge_qmaster/sge_execd port number).

🦋 name

Name of communication endpoint ("qmaster" or "execd"). A communication endpoint is a triplet of hostname/endpoint name/endpoint id (e.g. hostA/qmaster/1 or subhost/qstat/4).

✨ id

Id of communication endpoint ("1" for daemons).

---

okay that's the options, which is the chunky part — part 2 has the examples and the env vars and the see-also, keep scrolling bestie 🫶

✨ COPYRIGHT ✨

Okay bestie, the legal bit — and yes, we do still have to do it, even though it's giving ✨paperwork✨ energy.

For the full statement of rights and permissions, go read sge_intro(1). That's where the whole thing lives, word for word. No shortcuts, no vibe-summarising, just the actual text. 💜

---

And that's a wrap on QPING(1)! 🎀 You made it all the way to the bottom, which is honestly main character behavior. 💅

Version vibes: SGE 8.1.3pre 🦋 Dated: 2011-05-20 🌸

Now go ping something and slay, bestie. 🫶✨