When you send commands to a Windows, macOS, or Linux device through Swif, those commands might go into one of two queues: the Swif Agent queue or the MDM queue. These queues operate in parallel, which means Agent-based commands and MDM-based commands can run independently. However, each queue processes only one command at a time within its own pipeline.
1. How Swif Queues Commands
1.1 Agent-Based Commands
Typical Examples:
Running scripts
Installing software
Removing local user accounts
Collecting advanced system data
Queue Behavior:
The Swif Agent on the device periodically checks in with the server.
If commands are waiting for the Agent, it downloads and executes them one by one.
Additional commands remain queued until the current command finishes or times out.
1.2 MDM-Based Commands
Typical Examples:
macOS device profile pushes
Remote wipe
Passcode resets
Queue Behavior:
Swif’s MDM server notifies eligible devices (often via Apple Push Notification Service) about pending commands.
The device’s built-in MDM client processes them sequentially.
These MDM commands do not block Agent commands; they run in a separate, parallel queue.
2. Why Commands May Appear “Stuck”
Long-Running Agent Tasks
If the Agent is installing large software or collecting extensive data, subsequent Agent commands stay in the queue. MDM commands, however, can still proceed.
MDM Delays
macOS devices may not process MDM commands until they are online and receive APN notifications.
Timeout
Both the Agent queue and the MDM queue have a default 15-minute timeout. If a command doesn’t complete within that timeframe, Swif marks it as failed, and the queue resets.
3. Understanding “Last Connected”
Swif currently displays only “Agent Last Connected” in the console—showing when the Swif Agent last checked in. MDM commands do not have a separate visible timestamp.
4. Typical Scenarios
Agent Queue Busy, MDM Command Succeeds
A large Agent-based software install is running. You push an MDM profile at the same time.
The MDM command can proceed right away in its separate queue, even though the Agent queue is busy.
MDM Command Delayed, Agent Commands Continue
A macOS device is offline, so MDM commands remain pending. Meanwhile, the Agent can still process its own commands if the machine comes online and the Agent connects.
Deleting a User Triggers a System Refresh
After a “delete user” command completes, Swif recognizes a system change (the user list has changed) and automatically collects updated device information.
Any new commands submitted right after the user deletion might be added to the queue simultaneously (e.g., user deletion finishes, device info collection triggers, plus any user-initiated commands).
These commands then process one by one, potentially causing a short backlog in the Agent queue until each operation finishes or times out.
Last Connected Timestamp “Stuck”
The Agent is mid-command. It won’t update the timestamp until it finishes or hits the 15-minute timeout.
5. Best Practices
Avoid Overloading One Queue
Try not to stack multiple resource-intensive Agent commands (e.g., large software installs, user changes, data collections) in quick succession.
Plan for Automatic Data Collection
If you remove a user or perform any major system-altering command, Swif may automatically gather updated device info, which can add a temporary command queue step.
Give Commands Time
Large tasks can take several minutes. If they exceed 15 minutes, the system times out the command.
Use Parallelism Wisely
Remember that Agent and MDM commands do not block each other—feel free to push an MDM profile even if the Agent queue is busy.
Keep the Agent Updated
Newer versions of the Swif Agent handle concurrency and system refresh tasks more efficiently.
6. Checking Swif Agent Logs
If commands remain in a queue or fail unexpectedly, checking logs can help pinpoint the cause. See the Swif Data Refresh Guide for more info. Common log locations:
Windows
Event Viewer → Applications and Services Logs → Swif
Or
C:/Program Files/Swifteam/log.txt(path may vary by version)
macOS
/tmp/com.swifteam.swifteam.err.log
/tmp/com.swifteam.swifteam.out.log
Linux
/var/log/swif-agent.log
You may also enable debug or verbose modes if directed by Swif support.
7. High-priority commands (Device Lock / Full Wipe)
These two payloads skip the normal queue, deactivate lower-priority messages, and are pushed immediately (APNs on macOS; gRPC on Linux; 2-mins sync on Windows). The 15-minute “execution-timeout” applies only after the device has received the command—if the agent can’t finish within that window (almost never seen outside custom scripts), the job is marked Timed Out but is retried as soon as the agent or its watchdog (watchdog for Linux; service for Mac/Windows) restarts.
Meanwhile, a command that is still waiting in the queue but hasn’t reached an offline computer remains valid for 30 days. Killing the Swif agent with root access simply triggers the watchdog to relaunch it, at which point any pending lock/wipe is re-processed. On a healthy network the lock or wipe usually lands within seconds; delays beyond a few minutes are almost always network-latency or sleep-state related.
8. Troubleshooting Steps
Refresh the Console
Sometimes, the UI needs a manual refresh to show updated statuses.
Verify Device Connectivity
Ensure the device is online and can communicate with Swif.
Wait or Reissue Commands
If a command times out, consider reissuing it after confirming the device is ready.
Check Agent Logs
Look for any error messages or warnings that might indicate why commands are stalled.
Contact Swif Support
If commands remain stuck beyond 15 minutes or repeatedly fail, email us at support@swif.ai.
9. Key Takeaways
What to remember | Why it matters |
One queue (Agent ↔︎ OS & MDM) | Commands sent to the Swif Agent and those sent via Apple/Windows/Linux MDM channels run in separate queues, so they never block each other.
macOS
Windows
Linux
|
Triggered system refreshes | Certain actions—for example Delete User—make Swif launch an extra data-collection task. That task is queued like any other, so you may briefly see more “Pending” items until the refresh finishes. |
15-minute execution-timeout | After a device receives a command it has 15 minutes to succeed or fail. If it doesn’t respond in that window the job is marked Timed Out and the queue resets so later commands aren’t stuck. |
30-day delivery window | A command that’s waiting for an offline computer stays in the queue for up to 30 days before it expires. |
Lock / Wipe override everything | Selecting Lock Device or Full Wipe pauses lower-priority jobs; the critical payload is sent first (APNs on macOS; gRPC on Linux; 2-minute sync on Windows). |
Watchdog auto-recovers | If a user—even root—kills the Swif Agent, a companion service restarts it, re-checks the queue, and re-runs any pending commands. |
Real-world speed | On a healthy network, Lock/Wipe reach the endpoint in seconds; Windows might take up to 2 minutes; multi-minute delays almost always mean the Mac/PC is asleep, offline, or on a spotty link. |
Agent Last Connected | The only timestamp shown in the Swif console. It’s updated when the Agent checks in, not when a command finishes, so a long-running job can make the timestamp appear “stuck.” |
Understanding these behaviors helps you diagnose and resolve any perceived “stuck” commands more efficiently, ensuring a smoother device management experience. If you have further questions, feel free to reach out to us anytime!