Listing content of directory with absolute path is not equal to listing with relative path?

I launched Ubuntu 14.01 instance in AWS by using its API (with Python and Boto).

I changed properties of the root device - 30GB instead of the default 8gb and used magnetic disk standard instead of general ssd gp2.

After boot finished I found that /etc/resolv.conf symlink (-> ../run/resolvconf/resolv.conf) appears to be broken.

And than this happened:

root@ip-10-246-135-238:/etc# pwd
/etc
root@ip-10-246-135-238:/etc# ls ../run
udev
root@ip-10-246-135-238:/etc# ls /run
acpid.pid     atd.pid     crond.pid     dbus               initramfs  motd.dynamic       network                     plymouth   resolvconf    screen           shm   sshd.pid  udev                     upstart-socket-bridge.pid  user
acpid.socket  cloud-init  crond.reboot  dhclient.eth0.pid  lock       mount              network-interface-security  pppconfig  rsyslogd.pid  sendsigs.omit.d  sshd  systemd   upstart-file-bridge.pid  upstart-udev-bridge.pid    utmp

This environment is no longer up, so I cannot run any additional debug commands, but maybe someone could explain to me what happened here? How this is possible in the first place?

m1keil

Posted 2014-12-14T12:27:29.333

Reputation: 878

Answers

The only explanation I can think of is that you had accessed /etc from a symlink so ../ was not actually / but something else. For example:

$ tree ~/testdir
/home/terdon/testdir
├── bar
└── foo
    └── bar -> ../bar/

3 directories, 0 files

In the example above, foo/bar is a link to ./bar. Now, consider this:

$ cd foo/bar
$ pwd
/home/terdon/testdir/foo/bar ## Note that the path follows the link
$ ls ../
bar  foo

As you can see above, ls ../ listed the contents of ~/testdir and not ~/testdir/foo. So, if you accessed /etc through a link, the ../ would be the parent directory of the link and not the parent directory of /etc itself.

I have no idea what this link could have been. I don't see any likely candidates in my Ubuntu VM and the only run/udev instance I find is in /run itself. Still, if what you describe happened as you show and it was not just some weird bug, you were probably somewhere in a linked directory.

terdon

Posted 2014-12-14T12:27:29.333

Reputation: 45 216

1Thanks. You made me look in the right direction. I actually made silly mistake by mounting two different partitions on /. While this is not exactly what you are saying, your first sentence is correct: my ../ was not actually / – m1keil – 2014-12-14T12:57:37.560

@MichaelS ah, yes, a device mounted at / would also explain it. Thanks for the accept but since you've figured it out, you may as well accept your own answer and just upvote mine if it helped you. Accepting your own answer is perfectly fine.

– terdon – 2014-12-14T15:27:02.760

Re-reading terminal output revealed me the answer:

root@ip-10-246-135-238:/etc# mount -v
/dev/xvda1 on / type ext4 (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
/dev/xvdb on /mnt type ext3 (rw,_netdev)
/dev/xvdf on / type ext4 (rw)
/dev/xvdf on /mnt/image type ext4 (rw)

I actually had silly bug in my code that mounted /dev/xvdf on /.

m1keil

Posted 2014-12-14T12:27:29.333

Reputation: 878