When dealing with systemd's shutdown sequence, it's crucial to recognize that services stop in parallel according to dependency relationships defined in unit files. Unlike traditional init systems with linear shutdown sequences, systemd uses a directed dependency graph for both startup and shutdown operations.

While there's no direct --shutdown-order flag, we can use several approaches to predict the sequence:

# View shutdown targets dependencies
systemctl list-dependencies --reverse shutdown.target

# Alternative with more details
systemctl show --property="Before,After,Requires,Wants" *.service

The systemd-analyze tool provides powerful visualization options:

# Generate DOT graph of all units
systemd-analyze dot --to-pattern='*.service' | dot -Tsvg > shutdown-graph.svg

# Focus on shutdown-specific units
systemd-analyze dot --from-pattern='*shutdown*' --to-pattern='*.service'

Let's examine a web service that needs to stop before the database:

[Unit]
Description=Web Application
After=network.target postgresql.service
Before=shutdown.target

To verify this works as intended:

# Check ordering constraints
systemd-analyize verify /etc/systemd/system/webapp.service

# Simulate shutdown timing
systemd-analyze critical-chain webapp.service shutdown.target

For complex systems, consider these methods:

# Generate JSON output for programmatic analysis
systemctl show --property=Before,After --output=json *.service

# Check conflicts that might affect shutdown
systemd-analyze conflict webapp.service postgresql.service

Remember that actual shutdown timing depends on several factors:

• Service type (simple, forking, oneshot)
• Timeout settings (DefaultTimeoutStopSec in system.conf)
• KillMode configuration in unit files

When investigating shutdown sequences in systemd, it's crucial to recognize that services are stopped in parallel based on their dependencies. While you can't get an exact linear order, you can analyze the constraints systemd imposes through dependency graphs and unit relationships.

The most powerful command for this analysis is:

systemd-analyze dot --to-pattern='*.service' --from-pattern='shutdown.target' | dot -Tsvg > shutdown-deps.svg

This generates a visual dependency graph showing all services that need to stop before shutdown.target. The output requires Graphviz (dot) for visualization.

For service development, try these approaches:

# Show shutdown dependencies for a specific service
systemctl list-dependencies --reverse --all my-service.service

# Check ordering requirements
systemctl show -p After,Before my-service.service

# Generate critical chain analysis
systemd-analyze critical-chain my-service.service

The visualization will show:

• Red nodes: Services that must stop before shutdown
• Blue nodes: Optional services
• Arrows: Dependency relationships (After/Before directives)

Consider this unit file snippet (my-service.service):

[Unit]
Description=My Custom Service
After=network.target
Before=shutdown.target

[Service]
ExecStart=/usr/bin/my-service
TimeoutStopSec=30

To verify its shutdown position:

systemd-analyze verify my-service.service
systemd-analyze dot --to-pattern='*.service' --from-pattern='shutdown.target' | grep my-service

For complex systems, consider these additional tools:

# Show all units ordered by shutdown sequence (approximate)
journalctl -o json-pretty -u '*' | jq -r 'select(.MESSAGE | contains("Stopped")) | .UNIT' | sort -u

# Check shutdown performance impact
systemd-analyze plot > shutdown-timeline.svg