Forum menu
Nailed it.
I took out the tcpdump command and put some debugging in so that I could follow the execution of the script (I just created text files on the desktop, I'm sure there's a more elegant way but it worked). This showed me two things.
1) Nothing I put in the systemd unit made any difference to the execution of the script, it always ran even if the USB was unplugged. There must be a way of doing this, but I don't know what it is.
2) The wait code above does work. It'll sit there happily waiting until the USB is presented before continuing.
However, restoring the tcpdump command was still symptomatic, I'd end up with two mount points on a reboot. So I figured maybe the mount point is visible for some value of, but not yet accessible, or some such. After all, when you insert a USB key it takes a couple of seconds for the desktop to go "Do you want to open this drive?"
So, I stuck a 10s sleep command between the while loop and the tcpdump command. Rebooted and, what do you know, it works perfectly! 10s is probably excessive, but I'd rather err on the side of caution and I couldn't care less about a few seconds' delay.
If running it as a systemd service, then I can’t think of any reason you’d ever want to bg it
I've sussed this too I think. Using tcpdump at a command line hangs up the console until you ^C out of it. Predictably, it also does the same to a shell script. So if there were further commands I needed to run immediately after launching tcpdump I'd have to background it.
I'll write up a summary in a bit. Thanks all for your help.
If running it as a systemd service, then I can’t think of any reason you’d ever want to bg it
My suggestion was to run it from rc.local. If you don't background it, it'll prevent the completion of the rc.local script, both whilst it's waiting for the USB key to be mounted, and once tcpdump is running. This will prevent any other commands further down rc.local from running, and will also probably cause systemd to sulk because it'll think that that start up process didn't complete properly.
If you're setting it up as a proper systemd service, then there are various different modes you can use, depending on whether the command forks (Type=forking i.e. creates its own process in the background and then exits), or stays running in the foreground (Type=simple). When using systemd, the latter is generally preferable as systemd can then monitor the process and restart it if it dies.
As for the race condition of it creating the directory before mounting, you can do something like this:
while ! grep /media/pi/USBDISK /proc/mounts > /dev/null ; do sleep 1 ; done ; tcpdump ...
[i]pdw wrote:[/i]
If running it as a systemd service, then I can’t think of any reason you’d ever want to bg it
My suggestion was to run it from rc.local. If you don’t background it, it’ll prevent the completion of the rc.local script, both whilst it’s waiting for the USB key to be mounted, and once tcpdump is running. This will prevent any other commands further down rc.local from running
Yeah, as I mentioned in the bit just above what you're quoting 😉 (I had to go back to check I'd written that, but I presume you're quoting Cougar quoting me rather than snipping my post then repeating the bit you'd snipped 🙂 )
Good advice on checking /proc/mounts - I often enough do a sleep as Cougar is to make something work, but even if you don't mind waiting it's always better to do it properly rather than risk it breaking at some point in the future when there's an unusually long delay.
As for the race condition of it creating the directory before mounting, you can do something like this:
while ! grep /media/pi/USBDISK /proc/mounts > /dev/null ; do sleep 1 ; done ; tcpdump
Well blow me, that works. Nice work there, thank you so much.