Raspian rc.local pianobar

Home Forums Linux Raspian rc.local pianobar

This topic contains 7 replies, has 3 voices, and was last updated by  RChandra 6 months, 3 weeks ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #5095


    I have been working on a Linux project for a few weeks and though I’ve had my share of newbie issues I’ve gotten past every single problem except two.
    An auto start script for pianobar, the linux Pandora client. And an lcd issue which I’ll not bother addressing at this point. I do like to figure these things out on my own.

    The problem is I’ve tried to auto start pianobar on startup using Jessie lite and I have an issue with executing a command in rc.local.
    I have a working script in my /home/pi directory that starts pianobar manually but when I add the command to the rc.local file It starts but does not utilize the pianobar config script.

    For some brief history as this may be to specific for a general linux question, here’s what it does.
    When pianobar starts it reads pandora login credentials from a small text file including e-mail, password, and an updated tls fingerprint which is used to authenticate my Pandora session. For some reason when the rc.local file executes the command (sh /home/pi/pianobar.sh) it hangs at the login and does not start complete the startup process.
    I can start pianobar manually with a script ok or by typing aoss pianobar a the command line. but not rc.local

    Any ideas?



    Well, I’m just guessing here — not really being much of an expert on these things (actually none). But here is an idea or two:

    When you manually start the script, I assume you are not root. But, I expect that when you fire something off from rc.local, those things come up as if started by root.

    Then, there could be things like finding parts of the program due to different paths in effect. Any permissions or ownership problems?

    I assume you have gone thru the messages in /var/log to see if anything shows up there. And, dmesg doesn’t pick up anything.

    I think, if I was at a complete loss on this I would start dropping in some echo statements (either to the display, or to a log file), and see how far the failed script gets, and maybe why it fails.

    Since it hangs at the login, is it expecting some input from the user? And, if so can you change that script to read that from a file (or just hard code the expected response).

    If you try to fire it off from a cron job, does it fail there, also? Might be a little difference in what gets initialized after rc.local, and before the entire system has settled down.

    I’m out of straws to grasp at!



    I’m trying again to go through log messages. I’m not sure what I’m looking for so I’ve been opening the various log files one by one. I may just try learn another way to start the program automatically.
    In the rc.local file I put this pianobar command…
    _IP=$(hostname -I) || true
    if [ “$_IP” ]; then
    printf “My IP address is %s\n” “$_IP”
    sh /home/pi/pianobar.sh &
    exit 0
    this starts a script….

    #!/usr/bin/env bash
    aoss pianobar
    I don’t think it’s a permission issue as I’ve made the script executable. This is the first auto start script I’ve ever tried so I suppose I need something better or more robust than what I wrote. I know when I run the script manually after boot it works.

    New users everywhere seem to have issues getting pianobar to start at boot and a quite a few experienced people have said that rc.local is not the best way, they recommend an init script whatever that is. I think I need more general knowledge in running bash scripts.

    I’ve read people use cron, so I may try to find some good lessons on how that works as well. I’m starting to feel like I got in over my head but I do seem to learn a few things every day. I never imagined it would be this difficult to run a simple bash command at startup.

    Thanks for your input, I’m going to spend a little more time combing over the log files.

    • This reply was modified 1 year, 1 month ago by  Jim.
    • This reply was modified 1 year, 1 month ago by  Jim.


    Well, I’m not sure I’m really much help. But here are a couple thoughts that run thru my mind — as empty as it is at times.

    When you set your permissions I assume those are set for everyone.

    Doesn’t hostname -1 always return an IP address? In my case it is returning — which I think is close to the IP for the box. That would be for the loopback device, so should always be there.

    I think where you find reference to init scripts, that probably is a reference to the ones in the rc.* family, maybe in /etc/rc?.d.
    Interesting reading, if nothing else.

    And, as an afterthought — when you find a solution to your problem, please let us know. That may help others.

    As far as cron goes, do a man on cron and also crontab. Crontab is the user interface for editing the cron configuration. I generally use crontab -e –that seems to handle what I need. Just read the man crontab page first, especially as far as what edit package you will get hit with! I like to use nano (or pico) and that is as exotic as I need for my work — but in some installations crontab invokes some of the more sophisticated editors. The headers in the cron file are such to describe the format of each line.

    Have you tried just using your aoss pianobar in the rc.local script?

    And, please — when you find a solution to the problem, let us know. That information will help others.

    • This reply was modified 1 year, 1 month ago by  HotDawg.
    • This reply was modified 1 year, 1 month ago by  HotDawg. Reason: Additional comment


    I’ll definitely post the highlights, and especially the auto start solution, to this project. I’ve wanted to learn more about Linux and programming for years and these little Raspberry Pi computers are an ideal platform for me. I’ll post a couple photos when I’m done. Other than the speakers and case, the parts for this Pandora player are around $25. The Pi Zero $6, the PhatDac sound card $15. I’m going to gift the hell out of these things when I figure it all out.



    I can’t find an edit button to mark this posts description as solved but here it is…

    To auto-start a Pandora command line client like pianobar, I created a bash script by typing…
    sudo nano pianobar.sh
    In the text editor enter these three lines.

    #!/usr/bin/env bash
    aoss pianobar

    Save the file. Since I replaced the pi’s audio driver with alsa, the command is (aoss pianobar) in a standard pianobar install with the default pi audio driver, you would leave out the (aoss) part.

    Next alter the users profile which runs at startup.

    sudo nano /etc/profile
    At the bottom of the file add…

    sh /home/pi/pianobar.sh and save.

    And that’s it. If you have a properly configured pianobar install and a pandora account, this will auto start whenever the pi boots.

    There is a good wiki page detailing the pianobar installation process. Many people claim that the apt-get pianobar install is broken, but you simply needs to address a network error problem and add a (tls fingerprint) to your configuration file.


    With a couple of inexpensive components you can have a small hi-fi pandora player for about $30. This could easily fit inside a playing card box. The cheapest way to control the pandora functions would be to ssh into device, obviously not a user friendly approach. I’m working on a python script to control pianobar with just a few buttons and possibly add an lcd screen. Most of the functions are easily controlled with a single keyboard stroke however changing stations is a little more difficult since pressing “s” brings up your station list and without seeing it it’s kind of hard to make a choice.



    I’m glad you solved it! I had forgotten about the /etc/profile and such. I am familiar with the .profile files you can set up in a user’s home directory and fire things off when a user logs in.

    The Raspberry I have here is the latest, and I initially set it up using the Ubuntu installation. So far have it simply running a caching DNS server, and gradually getting that to take over the assigning of IP addresses on the LAN. Sure is a lot of overkill for that type of application.

    Next will be to hook in a couple big hard drives, probably in a raid configuration, and run my own little cloud backup sever.



    Any time something runs while logged in but not from system scripts like /etc/rc.local, the most likely culprit is environment. HOME is probably the environment variable which is used to locate those credentials. If it weren’t set to /home/pi for example, it’d probably never find them. Another common one is if it’s a graphical program, it will not have access to :0 and indeed will not have DISPLAY set to even find :0.

    I’d also say, if you’re going to start up stuff from rc.local or /etc/init.d/scripthere, it’d be an exceptionally good idea not to run as the superuser, so you could prefix the running of something with sudo -H pi somecommand or perhaps su – pi -c ‘somecommand with args’

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

Comments are closed.