Wikipedia:Reference desk/Archives/Computing/2015 October 25

= October 25 =

Linux Question: Running Commands at Startup...The Right Way
Hello all. I've been experimenting with a little Raspberry Pi-based music player for a while now. For a time, I was running Volumio, but I decided that was too easy or something. So recently, I've become more serious about finding an alternative, which for the time being I've settled upon MPD with a web front-end (so that it can be controlled with small handheld devices remotely), which I'm currently using ympd for.

I have run into a little hitch, however. To get around MPD's permissions issues, I've decided to run it as a user, but I would like for it to run only once on startup. This is a headless system, so it doesn't open a graphical desktop, which has been my traditional way to autostart programs/services. I started messing with .bashrc, but I soon realized it would run stuff I put there every time I would open a new shell (including when I log into it via SSH, which is frequently). It doesn't seem to break anything to do that, but I also find it to be pretty kludgy.

Looking for solutions on Google, I've found a few. In fact, it's so many, I'm confused about which way is the intended way to do things of this nature. I generally don't like the idea of hacking things with cron, so I'd prefer to avoid that (unless that is, in fact, the best way?). It's clear that .bashrc and .profile are not good solutions. I need to run this as a specific user, so I can't have it run as root. What is the most elegant solution here? Cheers! --Amordea (talk) 07:07, 25 October 2015 (UTC)


 * Assuming it's Raspbian (a Debian derivative) running the classic init system, you'd:
 * create a script in /etc/init.d (let's say you'd call it /etc/init.d/mpd) - copy one you find there already, and notice how it has to start the job and stop it, depending on the parameter passed to it in $1 (start/stop/reload/force-reload/restart)
 * create symlinks from /etc/rc0.d, rc1.d, etc. back to /etc/init.d/mpd.  The name of each symlink controls whether your service is started or stopped at the runlevel corresponding to that rcX.d entry. You can probably get away with just having /etc/rc2.d/S99mpd and /etc/rc6.d/K99mpd - the S means "start at this runlevel", and K means "kill at this runlevel. Runlevel 2 is the usual runlevel for raspbian systems, and runlevel 6 is the "we're shutting down" signal.
 * If you just follow the pattern of another daemon like sshd, you'll be fine. -- Finlay McWalterᚠTalk 08:06, 25 October 2015 (UTC)


 * Ah, yes. I am running Raspbian.
 * This answers a lot of questions I had about init.d (I follow you about how runlevels work and how the symlinks tie into init.d here), thank you, but I have to be quite honest here: I have managed to get pretty far in computer life without ever having to really grasp regex nor even much scripting. Editing a config file is one thing, but interpreting these init.d files is something very different for me. Looking at a few of these scripts I see they're each written quite differently. I wouldn't know how to re-purpose one for my use (or maybe they just look more intimidating than they really are?).
 * In a large part, I am doing this project in order to teach myself more about using Linux, though, so if this is the way I should go, then it looks like I may have my work cut out for me here.
 * I will have to tackle this again after some rest, I think. Already spent most of the night mucking around, trying to figure out how MPD works (good learning experience). Thanks for steering me in the right direction, though! --Amordea (talk) 09:13, 25 October 2015 (UTC)


 * The script probably doesn't need regexps or anything fancy. A basic init.d script looks like:


 * Knowing what to do specifically will depend on what your specific daemon wants and expects. I should note that most Linux systems are moving away from SystemV-style init (which is what's described above) to systemd, which is much more sophisticated (and concomitantly more complex). But systemd has support for init scripts too (although their own config settings allow for doing fancier things), so this isn't quite dying knowledge. -- Finlay McWalterᚠTalk 09:40, 25 October 2015 (UTC)


 * You said "Running Commands at Startup...The Right Way", and the right way is what Finlay McWalter has described, but if you want to do it an easier way, I believe many versions of Linux still support a much older, simpler mechanism, which is that you just add your own commands to the file, and those commands are executed once during startup. —Steve Summit (talk) 21:46, 27 October 2015 (UTC)


 * Yes, in practice, that's much better. In times of yore, one would often take the system down to runlevel 1 to do maintenance tasks. But modern systems have decent package managers that can do most patching when the system is running normally, and in any event they (especially things like a Pi) reboot quickly. I honestly can't remember the last time I took a system down to single-user mode. -- Finlay McWalterᚠTalk 22:59, 27 October 2015 (UTC)


 * Thanks so much for these insights you both! I admit I've been going down a bit of a rabbit hole, trying to look into how systemd works (which as I understand is new to Debian Jessie). I did manage to get MPD started as a service with systemd (which turned out to be quite easy and I just edited the .service file to run it as user 'pi'--so far no apparent permissions problems), but I could not figure out how to also run ympd this way (which I currently just have the program sitting as an executable in a directory I created for it).
 * I will be tinkering with this again tonight. The init script doesn't look near as complicated as it seemed to me at first, so I think I will try to get that working for ympd. And if that doesn't work, sticking the command in rc.local seems easy enough.
 * Thanks again for your help. I think I have a better grasp as to how each of these methods work. It was very confusing when I first approached this and found like six different ways to autostart programs and I could not tell which way I was supposed to do it. --Amordea (talk) 03:56, 28 October 2015 (UTC)

Google circles
Quick question. About once a week, I get a Google+ message that someone has added me to his circles. I'm not interested in making my own circles, but as I understand it, I would be able to see things they share with that circle, and they can see what I post, i.e. from their perspective it's like following someone on twitter? Ssscienccce (talk) 23:12, 25 October 2015 (UTC)


 * When you post a message, you can limit the view of that message to circles you have created. If I place you in one of my circles, I can limit the view of my messages to a circle that includes you. It is the opposite of "following" on Twitter. On Twitter, you make all messages public and people choose if they want those messages to be easily seen. In G+, the person who writes the message decides who should see it (which could be public). If they don't share it with you, you won't see it - even if you put that person in one of your circles. So, putting another person in one of your circles won't make their messages suddenly appear for you. They have to either make their messages public or have you in one of their circles. This should not be confused with the main G+ screen that shows messages from those in your circles that are shared with you. That is similar to Twitter, but not the same. Again, if I add you to my circle and you don't add me to yours, I will only see messages you post as public. 199.15.144.250 (talk) 12:44, 26 October 2015 (UTC)
 * Thank you! 15:02, 27 October 2015 (UTC)