XX-net/XX-Net · warning

remove %s fail:%r

Error message

remove %s fail:%r

What it means

While starting the Teredo IPv6 tunnel prober, the proxy tried to delete a stale log file (log_file) and the OS remove() call failed. The failure is only logged with xlog.warn; probing continues, so it is non-fatal noise in the ipv6_tunnel common path.

Source

Thrown at code/default/gae_proxy/local/ipv6_tunnel/common.py:43

        self.fd = open(log_file, "a")

    def write(self, content):
        self.fd.write(content + "\n")
        self.fd.flush()

    def close(self):
        self.fd.close()


pteredor_is_running = False


def new_pteredor(probe_nat=True):
    if os.path.isfile(log_file):
        try:
            os.remove(log_file)
        except Exception as e:
            xlog.warn("remove %s fail:%r", log_file, e)

    global pteredor_is_running, usable
    pteredor_is_running = probe_nat
    prober = teredo_prober(probe_nat=probe_nat)

    if prober.nat_type in ('cone', 'restricted'):
        usable = 'usable'
    elif prober.nat_type == 'offline':
        usable = 'unusable'
    else:
        usable = 'unknown'

    if probe_nat:
        pteredor_is_running = False
        log = Log()
        log.write('qualified: %s\nNAT type: %s' % (prober.qualified, prober.nat_type))
        log.close()
    return prober

View on GitHub (pinned to cfa5bc17b6)

Solutions

  1. Stop the other running XX-Net/teredo instance so the file lock is released
  2. Manually delete the stale log file once, then restart
  3. Run the proxy with permissions allowing deletion in its working/log directory
  4. Ignore the warning if IPv6 probing still succeeds (check subsequent nat_type result)
Defensive patterns

Strategy: try-catch

Validate before calling

import os
if os.path.exists(log_file):
    try:
        with open(log_file): pass  # probe lockability cheaply (best effort)
    except IOError:
        pass  # will warn on remove; acceptable

Try / catch

try:
    new_pteredor(probe_nat=True)
except Exception:
    ipv6_tunnel.disable()  # fall back to IPv4 direct

Prevention

When it happens

Trigger: new_pteredor() finds log_file exists on disk, calls os.remove(log_file), and the remove raises — e.g. the file is locked by another process, has wrong permissions, or the teredo process still holds it open on Windows.

Common situations: Windows file locking when a previous miredo/teredo instance is still running; antivirus holding the log; running without delete permission in the working directory; two proxy instances started concurrently.

Related errors


AI-assisted analysis of XX-net/XX-Net@cfa5bc17b6 (2026-08-27). Data as JSON: /api/errors/e32a47b6a99763f1. Report an issue: GitHub.