Show Linux or *nix permissions in octal

Like many others before me, I briefly Googled for "ls show octal permissions" (without quotes) and got next to nothing immediately useful: https://www.google.com/search?q=ls+show+octal+permissions

I would've written the solution to this thread since I got this idea from there, but unfortunately, it's closed: http://www.unix.com/unix-dummies-questions-answers/119538-ls-switch-view-octal-permissions.html

Solution: ditch ls and use stat instead---stat can format its output similar to date.

$ stat -c %a "${filename}"
644

Removed LUN and multipath reports "tur checker reports path is down"

When removing a LUN from a Red Hat Enterprise Linux 5 (RHEL 5) server, I ran into this interesting issue:

[root@server ~]# multipath -ll
sdat: checker msg is "tur checker reports path is down"
sdbt: checker msg is "tur checker reports path is down"
sdct: checker msg is "tur checker reports path is down"
sdt: checker msg is "tur checker reports path is down"

This is annoying and problematic since running pvs or something similar will cause the system to hang as it tries to access the missing LUN. It's briefly covered below, but see also the official documentation: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/removing_devices.html

1. Stop using the volume and umount
2. Remove it from software RAID or LVM volume group
3. Use multipath -l to get the block devices names (e.g., sda, sdb, etc.)
4. Use multipath -f mpathX
5. To flush outstanding I/O ("sync"), use blockdev –flushbufs device

6. Make sure applications and things are no longer referencing the device(s)
7. echo 1 > /sys/block/device-name/device/delete

multipathd -k results in ux_socket_connect error

On Red Hat Enterprise Linux 5 (RHEL 5), when trying to enter the multipathd shell using multipathd -k, I ran into the following error:

ux_socket_connect: No such file or directory

Because running multipath -ll generated the desired output I assumed (and we all know what assuming does!) and began Googling a solution... and it turned out multipathd was not actually running or even set to start on boot. Solution:

chkconfig multipathd on
service multipathd start
multipathd -k

Lesson learned.