Operating System - HP-UX
1748269 Members
3435 Online
108760 Solutions
New Discussion юеВ

fstyp change the timestamp of root (/) filessytem

 
skalai
Occasional Contributor

fstyp change the timestamp of root (/) filessytem

On 11iv3 systems , running fstyp changes the timestamp of / filesystem

# ll -d /
drwxr-xr-x 17 root root 8192 Feb 7 05:32 /
# fstyp /dev/vg00/lvol4
vxfs
# ll -d /
drwxr-xr-x 17 root root 8192 Feb 7 05:43 /
# date
Mon Feb 7 05:44:03 EST 2011
#

This does not happen on 11iv2 and 11iv1 systems.

Any idea is appreciated

8 REPLIES 8
Dennis Handly
Acclaimed Contributor

Re: fstyp change the timestamp of root (/) filessytem

Why do you care? Are you going to backup the whole filesystem because of that?
If this is important, you'll need to contact the Response Center.

Re: fstyp change the timestamp of root (/) filessytem

It looks like the implementation of fstyp changes quite a lot on 11iv3. If I run a tusc on an fstyp on 11iv3 I see it creating and opening a socket on the root filesystem:

socket(AF_UNIX, SOCK_STREAM, 0) .......................... = 5
getuid() ................................................. = 0 (0)
unlink("//fsdaemonSocket7540") ........................... ERR#2 ENOENT
bind(5, 0x7fffeea0, 94) .................................. = 0
chmod("//fsdaemonSocket7540", 0700) ...................... = 0
connect(5, 0x7fffeea0, 94) ............................... = 0
write(5, "\0\0\001\0\0\0\0\0\0\0\0\0\0\0\0".., 32) ....... = 32
sendmsg(5, "\0", O_RDONLY) ............................... = 1
read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0".., 272) ....... = 272
unlink("//fsdaemonSocket7540") ........................... = 0


On a 11iv1 box, this doesn't happen... presumably in 11iv3 fstyp communciates with another daemon to accomplish its task...

Sockets are normally created in a temp directory, but as fstyp is a /sbin command that needs to be available at single user mode, presumably it creates the socket in root.

The action of creating and unlinking the socket will obviously update the timestamp on root.

HTH

Duncan

I am an HPE Employee
Accept or Kudo
Jose Mosquera
Honored Contributor

Re: fstyp change the timestamp of root (/) filessytem

Hi,

Are you really sure that this change occurs by fstyp command execution?
A lot of processes could be doing this update, the root filesystem is higly susceptible to changes. Could you try this behavior over a dummy mounting point?

Rgds.
Dennis Handly
Acclaimed Contributor

Re: fstyp change the timestamp of root (/) filessytem

>Jose: Are you really sure that this change occurs by fstyp command execution?

Everyone is now sure based on Duncan's tusc analysis.
Jose Mosquera
Honored Contributor

Re: fstyp change the timestamp of root (/) filessytem

The Duncan's analisys is great but no one should feel uncomfortable by my request.

Rgds.

Re: fstyp change the timestamp of root (/) filessytem

Jose,

> Could you try this behavior over a dummy mounting point?

How do you suggest we do that? fstyp is run against the block or raw device for the filesystem, not against a mount point. If you mean by trying the fstyp on another filesystem (non-root), you get the same result...

I can run this on a HP-UX system which is effectively idle (just me logged in on pretty much a fresh install) and still get the behaviour that skalai describes:

# date
Mon Feb 7 16:08:06 GMT 2011
# ll -d /
drwxr-xr-x 19 root root 8192 Feb 7 16:06 /
# fstyp /dev/vg00/rlvol1
vxfs
# ll -d /
drwxr-xr-x 19 root root 8192 Feb 7 16:08 /
# date
Mon Feb 7 16:09:31 GMT 2011
# ll -d /
drwxr-xr-x 19 root root 8192 Feb 7 16:08 /
# fstyp /dev/vg00/rlvol1
vxfs
# ll -d /
drwxr-xr-x 19 root root 8192 Feb 7 16:09 /


HTH

Duncan

I am an HPE Employee
Accept or Kudo
Jose Mosquera
Honored Contributor

Re: fstyp change the timestamp of root (/) filessytem

A dummy filesystem with a respective mounting point I meant, excuse me the mixup! Everybody calm down please...
Dennis Handly
Acclaimed Contributor

Re: fstyp change the timestamp of root (/) filessytem

>Duncan: If you mean by trying the fstyp on another filesystem (non-root), you get the same result.

It is useful if you didn't have the tusc output. It says it has nothing to do with the FS in question. But doing a bdf on / to get the lvol would also indicate that.

>Jose: the root filesystem is highly susceptible to changes.

On one of my systems, / hasn't changed in 6 months.