Service start/stop shortcut

A kiosk-style FR201 typically launches a fullscreen browser or dashboard on boot via a systemd service. That’s great in production and miserable when you need to troubleshoot — every time you escape to a TTY, the service relaunches the dashboard before you can type anything useful.

The fix: drop two single-letter scripts (s to stop, r to restart) onto the device’s PATH. When you break out to the console, you can stop the service in two keystrokes (s, Enter) before it has a chance to take the screen back.

Create the shortcuts

Replace kiosk.service with the actual unit name on your device.

1. Write the s (stop) command to /usr/local/bin/:

   Create the stop shortcut

   sudo tee /usr/local/bin/s > /dev/null << 'EOF'
   #!/bin/bash
   sudo systemctl stop kiosk.service
   echo "Kiosk service stopped"
   EOF

2. Write the r (restart) command:

   Create the restart shortcut

   sudo tee /usr/local/bin/r > /dev/null << 'EOF'
   #!/bin/bash
   sudo systemctl restart kiosk.service
   echo "Kiosk service restarted"
   EOF

3. Mark both executable:

   Mark the shortcuts executable

   sudo chmod +x /usr/local/bin/s /usr/local/bin/r

/usr/local/bin/ is on every user’s PATH by default, so s and r work from any directory without an alias. Both call sudo, though, so they only do something for an account that has sudo rights. If your kiosk runs under a dedicated unprivileged user — and it should — see Why these need sudo below.

Use the shortcuts

When the dashboard is up and you need to break out:

1. Switch to a TTY (Ctrl+Alt+F2 usually works) or kill the X session, depending on how the kiosk is configured.
2. Log in. If you land on the kiosk account, switch to your admin user with su - pi and enter your password.
3. Type s and hit Enter. The service stops and stays stopped until you run r.

When you’re done troubleshooting, type r to bring the dashboard back.

Why these need sudo

Stopping a system service requires root, so both scripts call sudo. If your kiosk runs under a dedicated unprivileged account, that account can execute s and r but nothing will happen — it has no sudo rights.

That’s working as intended. The whole reason to run the browser under its own account is that a compromised session can’t control the service or anything else. So the sequence at the device is: break out to the console, su - pi, your admin password, then s. If you’re quick, you’ll beat the service’s restart delay.

Resist the urge to add a sudoers rule granting the kiosk user systemctl access. It hands back exactly the privilege the separate account was created to withhold, and it’s the one thing on the device an attacker who lands in the browser session would want.