On Sat, 2017-07-15 at 07:46 +0200, Tollef Fog Heen wrote: > Doesn't something like: > > [Unit] > Description=My hook for foo.link > After=foo.link > BindsTo=foo.link > > [Service] > Type=oneshot > ExecStart=/usr/local/sbin/whatever > RemainAfterExit=yes > > [Install] > WantedBy=multi-user.target > > work to hook into when a link unit is activated? > > (Or just a Wants and Before in the foo.link unit) When I discovered .link and .network files the first thing I looked up in the doco was whether that sort of thing was possible. I decided it wasn't and wrote it off as useless for me. Now you've made me check for real. After setting up the unit files you suggested I get this message in journalctl: Failed to add dependency on foo.link, ignoring: Invalid argument So now I'm fairly convinced the above isn't a thing. systemd unit files and udev unit files live in two different worlds - they can't refer to each other. That aside, it wouldn't work for my most advance use case anyway. My issue is I have boxes literally 1000's of km's away. Occasionally it all goes wrong, the only way to fix it is ssh in but "all" includes the internet connection. My fix was to detect when a mobile phone was plugged in via USB, then create a vpn connection home. This is all doable with a few lines in /etc/network/interfaces - the hard bit is detecting when some random USB device is a mobile phone. Standard udev rules can't do it, and so systemd.link being less powerful doesn't have a hope. This isn't a reflection on either of them really - it's a very specialised use case. However, I do expect them to provide an escape route. Udev does - it can run a program to decide. systemd.link can't.
Attachment:
signature.asc
Description: This is a digitally signed message part