mktemp - duplicate files/dirs ...

Under Leap 15, this simple assignment:

MOUNT_POINT=$(mktemp -d “/tmp/butmp.XXXX”)

gives me ONE directory entry.

But when executed as an action (script) from a udev rule (RUN+=…)
I consistently get TWO directory entries (with a different extension) ??

(same with file instead of directory)

What did I get wrong ?

Sorry, but I doubt people can do much which what you tell. Please be more explicit. Which names do you get., etc. Keeping all details a secret will not help anybody to get an Eureka moment.

I’ll try be more explicit… :wink:

The simple script (saved as “abu.sh”) assigns a name to the variable MOUNT_POINT, and in the meantime creates a temporary directory with that same name (as per “man mktemp”).
So i do get a name for MOUNT_POINT (e.g. “/tmp/butmp.eIXz”) and at the same time a directory is indeed created with that name ("/tmp/butmp.eIXz") - when run from the console…

But the purpose is to have this script executed as an action to a udev-rule (in my case: /etc/udev/rules.d):

SUBSYSTEM==“block”, ACTION==“add”, ATTRS{idVendor}==“174c”, SYMLINK+=“abul%n”, RUN+=“abu.sh”

But when i do plug-in that block device, I do get a name assigned to “MOUNT_POINT”, but TWO directories are created under /tmp/ (conform the same template).

So the variable MOUNT_POINT is assigned a name (e.g. “/tmp/butmp.om3T”), while two directories are created (e.g. “/tmp/butmp.om3T” AND “/tmp/butmp.rbyr”)…

I think there must a some problem here ?

I will also try to be more specific.

There is an important, but not easy to find feature on the forums.

Please in the future use CODE tags around copied/pasted computer text in a post. It is the # button in the tool bar of the post editor. When applicable copy/paste complete, that is including the prompt, the command, the output and the next prompt.

Then, why do you not post that script? There could be an error/misunderstanding there and how are we assumed to check that? At least it would provide us with the exect call of mktemp and not your vague: as per “man mktemp”

Then do such a call and show us what is created: the script execution command, it’s output and the ls -ls -l of what is created. Then we can see date/time/ownership …

Then show us the complete udev rule:

cat /etc/udev/rules.d/whatever-the-name-is

Etc.

This is very general for problem posting/asking for help:

Remind that we can not look over your shoulder and that we rely completely on your information. Also, you are now realy in touch with your problem, we aren’t,. So, do not assume that we have an intimate insight in your problem. Also do not assume people do what you try to do all the time and thus it is only a case of half explanation and then others say: of course he means …

Sometine in the past another member here said: we do not trust you, we only trust computer output. That is a bit harsh, but human people are notorious for skipping information, jumping to conclusions, etc. The best is to offer the real output because others may see what you didn’t.

…we do not trust you, we only trust computer output…

lol! I’ll remember this as a real good (and just) quote!

But back to business, here you have the rule, the script and the ouput (working as root on console)



hanoi:~ # cat /etc/udev/rules.d/10-abu.rules 
SUBSYSTEM=="block", ACTION=="add", ATTRS{idVendor}=="174c", SYMLINK+="abul%n", RUN+="/bin/abu.sh"

hanoi:~ # cat /bin/abu.sh 
#!/bin/bash
MOUNT_POINT=$(mktemp -d "/tmp/butmp.XXXX")
echo "$MOUNT_POINT" |  xxd > /tmp/buNAME.TXT
exit

hanoi:~ # /bin/abu.sh

hanoi:~ # ll /tmp/bu*
-rw-r--r-- 1 root root 68 Dec  7 10:29 /tmp/buNAME.TXT

/tmp/butmp.mOag:
total 0
drwx------  2 root root  40 Dec  7 10:29 ./
drwxrwxrwt 17 root root 380 Dec  7 10:29 ../

hanoi:~ # 


This is as it should be: one temporary directory has been created in /tmp

But when i do insert the usb-block device (referenced as ATTRS{idVendor}==“174c” in the udev-rule) in the usb-port I get two directory entries, like this:



hanoi:~ # ll /tmp/bu*
-rw-r--r-- 1 root root 68 Dec  7 10:35 /tmp/buNAME.TXT

/tmp/butmp.7BOE:
total 0
drwx------  2 root root  40 Dec  7 10:35 ./
drwxrwxrwt 18 root root 400 Dec  7 10:35 ../

/tmp/butmp.Zg7W:
total 0
drwx------  2 root root  40 Dec  7 10:35 ./
drwxrwxrwt 18 root root 400 Dec  7 10:35 ../

hanoi:~ # cat /tmp/buNAME.TXT 
00000000: 2f74 6d70 2f62 7574 6d70 2e5a 6737 570a  /tmp/butmp.Zg7W.


My question is really that simple: what do I do wrong ?

That is much better! Now I see that your script is in fact at /bin/abu.sh and not at abu.sh as you posted earlier and of which I had my doubts.

What I can imagine here is that on connecting the device the hardware sees two connections short after each other (trembling fingers, or bad contact, or …). Could you check with e.g. dmesg what is happening at connection?

Just a thought.

You see that I can if I want to :wink:

… the hardware sees two connections short after each other (trembling fingers…

Heaven forbid - i don’t drink that much ! (although i’m 68).

dmesg tells me (yes - i was absent between 7996 and 8232 …):


 7996.867819] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
 8232.670755] usb 2-2.1: new SuperSpeed USB device number 9 using xhci_hcd
 8232.691871] usb 2-2.1: New USB device found, idVendor=174c, idProduct=1153
 8232.691881] usb 2-2.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 8232.691888] usb 2-2.1: Product: AS2115
 8232.691894] usb 2-2.1: Manufacturer: ASMedia
 8232.691900] usb 2-2.1: SerialNumber: 00000000000000000000
 8232.693391] usb-storage 2-2.1:1.0: USB Mass Storage device detected
 8232.694828] scsi host4: usb-storage 2-2.1:1.0
 8233.728041] scsi 4:0:0:0: Direct-Access     ASMT     2115             0    PQ: 0 ANSI: 6
 8233.728890] sd 4:0:0:0: Attached scsi generic sg2 type 0
 8233.736389] sd 4:0:0:0: [sdc] 468862128 512-byte logical blocks: (240 GB/224 GiB)
 8233.736708] sd 4:0:0:0: [sdc] Write Protect is off
 8233.736717] sd 4:0:0:0: [sdc] Mode Sense: 43 00 00 00
 8233.736997] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 8233.743052]  sdc: sdc1
 8233.747543] sd 4:0:0:0: [sdc] Attached SCSI disk

But I do think you have a point: there must be something that ‘sees’ two connections.

Could it be the ‘automatic notification’ is the cause (remember: I’m working on Suse - Leap 15 and when I insert the block device I get a message form the device notifier presenting me the possibility to mount - which i cancel of course)? But then, I don’t know how to disable this notification…

Well, I found out that at 73 I realy drink less and less (but no decrease on non-alcoholic).

That notification is from the desktop, but it is of course triggered by udev and udisk. But, that mechanism will mount it for you (when you answer the notification or try to use it otherwise) on a place in /run/media/<user-name>/<some fs-identification> (or similar, the /run/media/ part is something that differs now and then).

That does not explain the two directories you get IMHO.

I know of only one way to suppress the desktop doing this. That is by having the device in /etc/fstab. The device identification must then of course be something that can be coupled to the device, lke a LABEL or an UUID.

BTW, I think you can get some confirmation of a double action by not overwriting

> /tmp/buNAME.TXT

but by adding

>> /tmp/buNAME.TXT

You will then have a history of the number of calls of the script.

Been there - done that, and yes:


hanoi:/tmp # cat buNAME.TXT 
00000000: 2f74 6d70 2f62 7574 6d70 2e54 634d 300a  /tmp/butmp.TcM0.
00000000: 2f74 6d70 2f62 7574 6d70 2e33 4534 550a  /tmp/butmp.3E4U.

My conclusion, it is not mktemp that acts double, but your script is called twice.

Any chance you have your udev rule a second time somewhere?
Again, just guessing and offering starting points for thought.

On Fri 07 Dec 2018 01:56:03 PM CST, hcvv wrote:

My conclusion, it is not mktemp that acts double, but your script is
called twice.

Any chance you have your udev rule a second time somewhere?
Again, just guessing and offering starting points for thought.

Hi
Sounds possible, check in /lib/udev/rules.d/ also the number is
important, 10-* is very low down the pecking order if you inspect the
main udev directory. I would suggest 60-* or even 99-*.

You can also monitor what is happening via the udevadm command;


udevadm monitor


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.25-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Spot on !

Any chance you have your udev rule a second time somewhere?

Nope - but changed the names (cfr infra)

Again, just guessing and offering starting points for thought.

You’ve already solved more than I did :wink:


hanoi:~ # cat /etc/udev/rules.d/10-abu.rules 
SUBSYSTEM=="block", ACTION=="add", ATTRS{idVendor}=="174c", SYMLINK+="abul%n",RUN+="/bin/abu_01.sh"
hanoi:~ # cat /bin/abu_01.sh 
#!/bin/bash
date +%M:%S:%N >> /tmp/buTIME.TXT
hanoi:~ # cat /tmp/buTIME.TXT 
51:42:410969346
51:42:514929849

… and that problem is documented - so yes: you saved my day :slight_smile:

Glad to be of help.

After you provided the maximum of information, it is only working step by step, trying to let your brain not jump/skip. It often works, even if one does not know all the details behind it (I know about edev rules, but I am not fluent with them).

The problem was that the USB device ‘as such’ and the (only) partition, both triggered an action with the defined rule !

So i had to change the rule, to designate only the partition (and in the meantime taking into account Malcolm’s remark!)


hanoi:~ # cat /etc/udev/rules.d/90-abu.rules
SUBSYSTEM=="block", ACTION=="add", ATTRS{idVendor}=="174c", ENV{ID_PART_ENTRY_UUID}=="3b0dfc94-01", SYMLINK+="abul%n",RUN+="/bin/abu_01.sh"

Got the ID_PART_ENTRY_UUID from:


hanoi:~ # udevadm info --name=/dev/sdc1 | grep -i id_part
E: ID_PART_ENTRY_DISK=8:32
E: ID_PART_ENTRY_NUMBER=1
E: ID_PART_ENTRY_OFFSET=2048
E: ID_PART_ENTRY_SCHEME=dos
E: ID_PART_ENTRY_SIZE=468858880
E: ID_PART_ENTRY_TYPE=0x83
E: ID_PART_ENTRY_UUID=3b0dfc94-01
E: ID_PART_TABLE_TYPE=dos
E: ID_PART_TABLE_UUID=3b0dfc94

and now I have only ONE run of the script :slight_smile:

Thanks to you all!

Congratulations.

Yes, there was one other thing that was not realy covered in your original probem description: the nature of the device.

Somewhere in the background of my brain I “assumed” that it probably was mass strorage, but did not pay any attention to that. And as all know “assuming” is the start of a confusing discussion. lol!