Found it. > root at d3photo_test_development:/storage# grep -r -i 'timeout' /lib/udev/ > /lib/udev/rules.d/99-vmware-scsi-udev.rules:ACTION=="add", SUBSYSTEMS=="scsi", ENV{DEVTYPE}=="scsi_device", ATTRS{vendor}=="VMware*" , ATTRS{model}=="Virtual disk*", ATTRS{timeout}=="?*", ATTR{timeout}=“180" > /lib/udev/rules.d/99-vmware-scsi-udev.rules:ACTION=="add", SUBSYSTEMS=="scsi", ENV{DEVTYPE}=="scsi_device", ATTRS{vendor}=="VMware*" , ATTRS{model}=="VMware Virtual S", ATTRStimeout}=="?*", ATTR{timeout}=“180" > /lib/udev/rules.d/50-firmware.rules:# failed; necessary to avoid long timeouts with CONFIG_FW_LOADER_USER_HELPER=y > /lib/udev/rules.d/56-lvm.rules:OPTIONS+="event_timeout=180” I’m making them all 900 seconds to see if that fixes the timeout. > On Jun 13, 2018, at 8:58 PM, Ryan Coleman <ryan.coleman at cwis.biz> wrote: > > Any ideas on the timeout issue? Stops at 180 seconds and when checking with > >> udevadm info -a -n /dev/sdc > > > I don’t get receive any feedback that suggests it’s that length (I have a result of 10 and 30 from the card reader/device, but not the card/device itself. > > > > >> On Jun 13, 2018, at 6:42 PM, Ryan Coleman <RYAN.COLEMAN at CWIS.BIZ> wrote: >> >> >> >>> On Jun 13, 2018, at 11:54 AM, Iznogoud <iznogoud at nobelware.com> wrote: >>> >>>> >>>> This works: https://serverfault.com/questions/766506/automount-usb-drives-with-systemd <https://serverfault.com/questions/766506/automount-usb-drives-with-systemd> >>>> >>> >>> This is great info. I have been dealing with udev programmatically recently >>> and I have learned a lot. >> >> I wish there was more out there on the subject, it’s felt like I’ve been pulling teeth just to get this far. >> >>>> Mostly. It doesn’t unmount on removal but that’s a small concern. >>>> >>> >>> As I was thinking about this, it occured to me that there is no clear way to >>> unmount a USB filesystem. And I mean, you cannot just anticipate the USB being >>> yanked out of the system... And, I saw what you wrote above, and I also read >>> the solution on the link, and could not help but think that you need a way of >>> doing a clean unmount. >> >> There’s a solution, actually… >> >> CRON that runs every minute… it executes a file, deletes the file, touches the file, changes it permissions. >> >> Then there’s the script that runs on the insert that copies the contents of the card to the computer, in this case just the following file extensions: >> JPG, CRW, CR2, NEF >> >> That goes through the copy process, creates all the database hooks and renames the source files and then writes to the aforementioned file from the CRON a series of commands: >> mkfs >> umount >> >> And that gets executed at the top of the next minute by root. >> >>> The problem is that you can corrupt the filesystem on the USB drive/stick, >>> especially if there have been changes made (like deleting/writing files). >>> (It appears to be a "small concern" for you.) >> >> Correct. Which is why I’d like to avoid it. And I haven’t done the above stated commands but I do have the .sh content being written every time and I have the .sh that will do the CRON task written, but not the CRON hooks. Working with a limited VMDK on my laptop right now I need to work around the UDEV timeout of 180 seconds before I can move down this path. >> >> But it’s looking promising. >> >> >>> So, this brings me to the higher level question on what you are trying to do. >>> Having people just putting in USB drives and expecting that they get full >>> functionality is a fallacy. But you can have people put in the USB drive, get >>> files _from_ it, and then unplug it. In this case you would force read-only >>> mounting, and I expect all would be fine. In the case that you want the data >>> on the USB drive to be able to be altered, you will need to have some way of >>> allowing the unmounting of the drive. The real problem is making users do it… >> >> This is a ‘headless’ photo management server that will have a web presence only. The one thing I haven’t quite worked out (and will be doing in the future only) is how to tell the user that the card is ready to be removed from the drive. It is likely that this will include an arduino or pi device in the computer case that fires a series of relays that turns on and off three-stage LEDs. >> >> I’ve been working on this project in my head for years and I’m finally moving forward on it. >> >> — >> Ryan >> >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list