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.

Cron not working for normal user

Recently I ran into an interesting "issue" where a user's cron job wouldn't work and restarting the cron daemon did no good. Having checked the /etc/cron.allow and /etc/cron.deny files, I found nothing relevant, and so I Googled the error found in /var/log/messages:

Apr  9 12:31:01 server crond[8993]: Authentication token is no longer valid; new one required.

No password was necessary for this account, so to the system, it was a "locked" account, whereas to me, it was a service account.

[root@server ~]# grep username /etc/shadow
username:!!:13306:0:90:14:::

 Setting a password resolved this.

MaxRequestLen

The following error:

[Sat Jun 11 14:33:51 2011] [warn] [client 98.30.32.199] mod_fcgid: HTTP request length 131533 (so far) exceeds MaxRequestLen (131072)

Requires a review of the FcgidMaxRequestLen or MaxRequestLen parameter:

http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen

Fix: set value (in bytes) for FcgidMaxRequestLen inside httpd.conf or apache2.conf.

Renovatio

The original ErrorLog page grew rather long, and as a Wiki, made maintenance a big of a pain, seeing as all content went into the same page. This format strives to be a little different. Chronology is easier to maintain, and tags allow for easier sorting than do "folder" like structures of headings or titles.

Original: http://code.google.com/p/sna/wiki/ErrorLog

Rest of the wiki: http://code.google.com/p/sna/wiki/