isu-hosts

name

isu-hosts

description

This skill should be used when the user asks to "ssh into isu1/isu2/isu3", "check the production server", "look at webapp logs", "tail webapp.log", "look at mysql slow log", "check nginx on the competition host", "deploy", "restart the webapp", or otherwise needs to connect to or inspect the ISUNARABE 2026 competition servers (isu1, isu2, isu3) from the local workstation. Do NOT use this skill if already running on one of the isu hosts — outbound SSH between competition hosts is not configured.

isu-hosts

Connect to and operate the three ISUNARABE 2026 competition servers (isu1, isu2, isu3) from the local workstation. See repo-root CLAUDE.md for project topology and deploy flow; this skill covers the SSH/operations side.

Current role assignment

• isu1 — nginx (front reverse proxy, receives bench traffic) + app process
• isu2 — app process
• isu3 — MySQL (see DATABASE_URL in env.all.sh)

Roles may shift during the competition to rebalance load; re-check env.all.sh and nginx.conf before assuming. Update this section when the assignment changes.

Pre-flight self-check (mandatory)

Before issuing any ssh isuN ... command, confirm the current machine is the local workstation, not a competition host. Outbound SSH from isu1/isu2/ isu3 to the others is not set up, and trying it will fail confusingly.

Check with:

hostname; hostname -I 2>/dev/null

Abort and tell the user to operate locally if any of these match:

• hostname is isu1 / isu2 / isu3 (or any string containing isu)
• hostname -I shows an address in 192.168.0.0/24
• A file /home/isucon/env.sh exists (only present on competition hosts)

On the competition host, run commands directly (no ssh isuN prefix) and treat isuN references in this skill as "the current host."

Connecting

SSH aliases isu1, isu2, isu3 are configured in the workstation's ~/.ssh/config. Default user is isucon. Prefer one-shot commands (ssh isuN '<command>') over interactive sessions for log peeks and status checks — easier to capture output and parallelize.

To run the same probe on all three hosts in parallel, issue three Bash tool calls in a single message rather than sequentially.

Service control

Service unit: nrb2026-webapp.service (defined in systemd/system/ in this repo, mirrored to /etc/systemd/system/ on hosts by deploy.sh).

ssh isuN 'sudo systemctl status nrb2026-webapp.service'
ssh isuN 'sudo systemctl restart nrb2026-webapp.service'
ssh isuN 'sudo journalctl -u nrb2026-webapp.service -f'

Webapp listens on port 80 directly (no TLS). nginx config: nginx.conf in this repo, deployed to /etc/nginx/nginx.conf. Reload with ssh isuN 'sudo nginx -t && sudo nginx -s reload'.

Logs

• Webapp stdout+stderr: /var/log/webapp.log — rotated by deploy.sh to /var/log/webapp.log.<timestamp> at every deploy.
• MySQL slow log: /var/lib/mysql/mysql-slow.log — same rotation pattern.
• nginx access/error: standard /var/log/nginx/.
• systemd journal: journalctl -u nrb2026-webapp.service.

Tail recipes:

ssh isu1 'sudo tail -f /var/log/webapp.log'
ssh isu3 'sudo tail -f /var/lib/mysql/mysql-slow.log'

MySQL access

DB host follows DATABASE_URL in env.all.sh (currently isu3). Re-check that file before assuming — the team may move MySQL between hosts to balance load.

ssh isu3 'sudo mysql nrb2026'
ssh isu3 "sudo mysql nrb2026 -e 'SHOW PROCESSLIST'"

Schema and seed data live at /home/isucon/webapp/sql/ on the host (and webapp/sql/ in the repo). POST /api/initialize resets to bench-expected initial state.

Deploying changes

From the local workstation (not from a host):

./push.sh                           # build + upload binary to S3
ssh isu1 './git/deploy.sh'          # then on each host that should update
ssh isu2 './git/deploy.sh'
ssh isu3 './git/deploy.sh'

deploy.sh self-updates from git first, so commit and push before invoking it. It restarts nrb2026-webapp.service, reloads nginx, and rotates the webapp + slow logs — the rotation is convenient for "fresh log per bench run" workflows.

To deploy to all three in parallel, issue the three ssh ... ./git/deploy.sh calls in a single message.

Performance analysis

Per-host CPU/IO snapshot:

ssh isuN 'top -bn1 | head -30'
ssh isuN 'pidstat -u -d 1 5'

Slow-query digestion (run on the host that has the log file, typically isu3):

ssh isu3 'sudo mysqldumpslow -s t /var/lib/mysql/mysql-slow.log | head -50'

If pt-query-digest or alp is installed, prefer those for richer output. Don't install heavy tooling on the hosts mid-competition without a clear reason — keep changes reversible.

What not to touch on the hosts

Per regulation (docs/regulation.md § 5, manual § 4.1) — modifying any of these disqualifies the team:

• /etc/systemd/system/isuwari.* and anything under /opt/isuwari/
• the isuadmin user, its account, group, sudoers, or ~/.ssh/authorized_keys
• frontend static files at /home/isucon/webapp/public/ (and the repo's webapp/public/ — never edit)

For all other changes, edit files in this repo and deploy via push.sh + deploy.sh. Direct edits on the hosts are fine for ad-hoc diagnosis (mysql queries, tail, systemctl restart) but should not be the source of truth for config — deploy.sh will overwrite nginx.conf and the systemd unit on next run.

Competition-end constraint

All 3 hosts must be running at competition end (manual § 4.4, § 7). Stop or reboot hosts via the AWS console freely during the competition, but restart them all before the deadline — a stopped host means the 追試 reboot check fails and the team is disqualified.