Debian Squeeze and Sheevaplug LED control

[jk-menifee]

First, one of these days I'm going to get around to writing a success story but in a nutshell my Sheevaplug has completely replaced a desktop computer that used to run Ubuntu and served as a multipurpose server, in the process saving us a lot of electricity, noise, and heat. My wife's happy that the old computer is gone and I'm happy that I still have a machine running all the time.

I'm running Debian Squeeze, installed as per the very excellent instructions on the www.cyrius.com Web site. I've read up on controlling the SheevaPlug LED's in these forums, in the wiki, and everywhere I can find on the Internet, and it seems so straightforward. Everyone manages to control them using the "trigger" file in /sys/devices/platform/leds-gpio/leds/plug:green:health or the alternate symlinked location of /sys/class/leds/plug:green:health. This is what happens when I try:

Code:

john@shiva:~$ cd /sys/class/leds/plug\:green\:health
john@shiva:/sys/class/leds/plug:green:health$ ls -l
total 0
-rw-r--r-- 1 root root 4096 Dec  1 17:04 brightness
lrwxrwxrwx 1 root root    0 Dec  1 17:04 device -> ../../../leds-gpio
-r--r--r-- 1 root root 4096 Dec  1 17:01 max_brightness
drwxr-xr-x 2 root root    0 Dec  1 17:04 power
lrwxrwxrwx 1 root root    0 Dec  1 17:00 subsystem -> ../../../../../class/leds
-rw-r--r-- 1 root root 4096 Dec  1 17:04 trigger
-rw-r--r-- 1 root root 4096 Dec  1 17:00 uevent
john@shiva:/sys/class/leds/plug:green:health$ cat trigger
none nand-disk timer [default-on] mmc0
john@shiva:/sys/class/leds/plug:green:health$ sudo echo "none" > trigger
-bash: trigger: Permission denied
john@shiva:/sys/class/leds/plug:green:health$ sudo ls
[sudo] password for john:
brightness  device  max_brightness  power  subsystem  trigger  uevent
john@shiva:/sys/class/leds/plug:green:health$ sudo echo "none" > trigger
-bash: trigger: Permission denied

I should note that for security reasons I have the root account disabled, using root via sudo. There is a very interesting clue therein: I am not even prompted for my password before getting the "permission denied" message. That's why, in the code section above, I put in the "sudo ls": so you can see that I was prompted for my password by "sudo ls" but not by the sudo echo command.

I just did a full system update (apt-get update;apt-get upgrade) and reboot and the problem is still happening. uname -a reports:

Code:

john@shiva:~$ uname -a
Linux shiva 2.6.32-5-kirkwood #1 Fri Nov 26 07:01:06 UTC 2010 armv5tel GNU/Linux

Incidentally, the intended use here is to tell me when it's okay to unplug my mp3 player after updating the podcasts on it. I have a udev script that watches for the mp3 player to be plugged in, then launches a Python script to update the podcasts in the background. The heavy lifting is done by hpodder, which is called by the Python script; the Python script just deletes and copies files. Without the LED control, I have to either power up a laptop to check if the script completed, or wait 15 minutes so that I can be sure the script is done. I thought the LED control would have been the easiest part of this application but unfortunately not :-(

Thanks in advance for any help you may be able to provide.

John K.

[birdman]

Just a thought - does your sudoers file let you use echo?

[jk-menifee]

Yes; the /etc/sudoers file is normal, as provided in the distribution; and these commands work fine:

Code:

john@shiva:~$ sudo echo "testing"
testing
john@shiva:~$ sudo echo "testing" > test.txt
john@shiva:~$ cat test.txt
testing

Thanks,

John K.

[sfzhi]

these commands work fine:

Code:

john@shiva:~$ sudo echo "testing" > test.txt

No offence, but you don't seem to understand what exactly you have just done. You have written the output of 'sudo echo "testing"' to a file 'test.txt'. Now try this:

Code:

ls -l test.txt

Who is the owner of the file?
You probably have already got the idea why you get "access denied" with LEDs?

[jk-menifee]

Yes, I see what you mean, the file is owned by the regular account and not by root. Now I see that redirection is being performed differently from how I thought. You learn as you go, right? Since my full-time job is not computer engineering I only have my spare time to pick up these subtleties.

At any rate, I became root using "sudo bash" (not sure why "su" doesn't do it) and I can control the LED's. Well, at least I don't get an error; I'm not at home to visually inspect the lights. So it looks like this problem is resolved. Thanks for the help. Glad it wasn't a more major problem; just old-fashioned operator error.