[ftok()-related] Can 'st.st_dev of the same file' be changed between reboots on HP-UX?

[Alex_Vinokur]

>> Where to pick? Via any program that "works" with myexe.

> Use the myexe executable itself.

Our situation is more complicated. We need several ftok-files, their names depend on some input parameters from database.

OK, we will think of that.

Dennis, thank you.

[Dennis Handly]

>We need several ftok-files

You can use the same file and up to 256 values of "id".

[Alex_Vinokur]

>> We need several ftok-files

> You can use the same file and up to 256 values of "id".

 Our "id's" are actually some strings (that are selected from database).

But there is another problem: file "myexe" may be updated (i.e. re-created) from time to time.

We will investigate another solution (possible using also existing ftok()-function).

Thanks.

[Dennis Handly]

>another problem: file "myexe" may be updated (i.e. re-created) from time to time.

Are there multiple executables that access the shared memory segment?  Or you want it to stick around after you update myexe?

I assume you realize that if you file isn't on NFS, you don't have to worry?

[Alex_Vinokur]

>>another problem: file "myexe" may be updated (i.e. re-created) from time to time.

>Are there multiple executables that access the shared memory segment?  Or you want it to stick around after you update myexe?

No, we don't have multiple executables that access the shared memory segment. The only executable creates (or attaches) different shared memory segments, Names of ftok-files are built on basis some info from data base.

>I assume you realize that if you file isn't on NFS, you don't have to worry?
....

1. It seems that I don't understand this issue. Where may file be: on NFS, something else?

2. But we actually came across this problem: ftok() returned other key for the same non-recreated file between reboots.

Thanks

[Dennis Handly]

>1. Where may file be: on NFS, something else?

Well more precisely, somewhere where it can be unmounted and mounted.  With the automounter, this is transparent.

>2. But we actually came across this problem: ftok() returned other key for the same non-recreated file between reboots.

On HP-UX and not NFS or umount/mount?

[Alex_Vinokur]

>>1. Where may file be: on NFS, something else?

>Well more precisely, somewhere where it can be unmounted and mounted.  With the automounter, this is >transparent.

I am not familiar with that issue.

>>2. But we actually came across this problem: ftok() returned other key for the same non-recreated file between reboots.

>On HP-UX and not NFS or umount/mount?

Dennis, sorry. My mistake.

We came across that on Linux. After that I started to check the ftok()-problem on other platforms.

Thanks

[Dennis Handly]

>We came across that on Linux.

As far as I know this only happens transparently with NFS and automounter.  Or some sysadmin manually unmounting and mounting filesystems.

Were there any other cases for Linux?

[Alex_Vinokur]

---

@Dennis Handly wrote:

>We came across that on Linux.

As far as I know this only happens transparently with NFS and automounter.  Or some sysadmin manually unmounting and mounting filesystems.

Were there any other cases for Linux?

---

About other cases for Linux - I don't know. 

I came accross that accidently, because it happened on Linux-machine that I have nothing to do with it.

How was the problkem detected?

While each reading the ftok file I write to that file   some relevant info, including generated Key (see attachment  TC_SHMTOK1_avinokur_TTT2_TTT1.docx).

In addition, on request we can get brief info about ftok-file (see attachment FtokFilesInfo.docx), that includes all generated Keys for ftok-files.

I was asked about something for that machine and accidently detected that some row in  FtokFilesInfo.docx contained 3 keys (not the only key, as it was expected).

It seems, that two keys were from the same reboot interval (so, here we have problematic situation).

Third key was from other reboot interval  (so, it may be OK).

I think, we should check generated keys within the same reboot interval (not only write to ftok-file).

Thanks.

[Dennis Handly]

>How was the problem detected?

>While each reading the ftok file I write to that file  

> /devjuser1/jp/ccjp/avinokur/tmp/shm_keys_holder

Did someone remove the file since it was in "tmp"?