View Single Post
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#34
Originally Posted by Mentalist Traceur View Post
Partial answer to my own question: /proc/mounts is where the actually accurate mounts data is, 'mount' with no arguments seems to print out a list that doesn't reflect the current mounts, at least at that stage of boot. *Shrug*
You just opened the "/etc/mtab vs /proc/mounts (or /proc/self/mounts)" pandora box

The actual information regarding mounted filesystems (as seen by the kernel) is in /proc/mounts (or /proc/self/mounts if you want to be chroot-compatible).

The program "mount" writes to /etc/mtab. The program "umount" writes (deletes lines from) /etc/mtab.

Normally /etc/mtab contains the same information as (or rather, information consistent with) /proc/mounts.

However if the computer crashes it doesn't get a chance to delete /etc/mtab, so upon reboot /etc/mtab will contain stuff that possibly is not relevant anymore. For that reason some people make /etc/mtab be a symlink to /proc/[self/]mounts. However this breaks other stuff.

Ideally /etc/mtab should be wiped during (early) boot, i.e. before anything is mounted. I don't know (at the moment) if/how Maemo5 handles this.

EDIT: In /etc/init.d/rcS you have
Code:
mount -n -o size=64M,nosuid,nodev,noatime -t tmpfs tmpfs /dev/shm
and a bit later
Code:
rm -f /etc/mtab
cat /proc/mounts > /etc/mtab
and for completeness, if I look in my /dev/shm I have a 20-byte file called "sem.nokiacal" containing, in hex:
"01000000 00000000 00000000 00000000"

/usr/bin/cal-tool uses libphread.so, so I guess it uses sem_open(3) to create a named semaphore. It is (I think) the kernel which takes care of creating the named file under /dev/shm.

so basically sem_open("/my_semaphoe", ...) will create /dev/shm/sem.my_semaphore

Last edited by reinob; 2013-11-05 at 08:50.
 

The Following 5 Users Say Thank You to reinob For This Useful Post: