1

I put my python script as boot running(rc.local) on my headless Rpi 3B+. It meant to controls three identical devices through serial cable and I am using GPIO PINS[17,27,22] for the software serial.

It works well from putty CLI, but with boot run mode strangely it works only one device. I run my script with rc.local method and at least one device start to work with Rpi so I assumed boot run setting is fine.

What I don't understand is why only one device(No.2) works but others just doesn't react, somehow I am suspicious about how Rpi GPIO initializing process while booting mode. If this gpio Pins sends alot of garbage signals while initializing so device can't react when real script starts? Because I have to reboot the devices(No.1 and 3) while Device No2 working, then device 1/3 start to work fine. So I guess Rpi invoke buffer overflow of the devices. For some reason device 2 is fine though.

Anybody knows about it??

  • Please take note that using /etc/rc.local has limitations due to Compatibility with SysV. We have seen many problems here on this site using it. Following the recommendation of the developers from systemd you should avoid using it. You should use a systemd Unit file instead to start your service. – Ingo Aug 31 at 15:14
  • @Ingo Thank you so much for the tip. I was just about to try that option now. I will update if it works. Yes, I knew also from the experience before that /rc.local seem not really stable solution. As I don't have knowledge as deep to figure out why and what is exactly differences, would be good if someone could explain or having proper source about differences between solutions. Actually most articles(for DIY or beginners) deals with rc.local as if it is proper solution for boot up running... – YJL Aug 31 at 15:30
1

OKAY, I made it by systemd. I know there is plenty of information to do, but I put the answer for myself and for others who needs.

SYSTEM : RPI 3B+ / raspbian PROGRAM : infinite loop written by python 2.7 ENVIRONMENT AND REQUIRED IO : GPIO switching (22,27,17) for software-serial / 5,6 for normal callback switching

tried rc.local but it wasn't successful. And usually it is quite unstable way to do. So please do it for systemd method if anyone need to do.

I found most simple solution below link posted by "Frollo" https://www.raspberrypi.org/forums/viewtopic.php?t=197513

You can execute it by python hello_world.py. If you get boring reading so many hello worlds, press Ctrl+C (or Cmd+C on OSX) to stop it. Save this file as hello_world.py in your home folder (home/pi/). Now we're going to define the service to run this script:

cd /lib/systemd/system/
sudo nano hello.service

The service definition must be on the /lib/systemd/system folder. Our service is going to be called "hello.service":

[Unit]
Description=Hello World
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/python /home/pi/hello_world.py
Restart=on-abort

[Install]
WantedBy=multi-user.target

Here we are creating a very simple service that runs our hello_world script and if by any means is aborted is going to be restarted automatically. You can check more on service's options in the next wiki: https://wiki.archlinux.org/index.php/systemd.

Now that we have our service we need to activate it:

sudo chmod 644 /lib/systemd/system/hello.service
chmod +x /home/pi/hello_world.py
sudo systemctl daemon-reload
sudo systemctl enable hello.service
sudo systemctl start hello.service


sudo chmod 644 /lib/systemd/system/hello.service
chmod +x /home/pi/hello_world.py
sudo systemctl daemon-reload
sudo systemctl enable hello.service
sudo systemctl start hello.service

For every change that we do on the /lib/systemd/system folder we need to execute a daemon-reload (third line of previous code). If we want to check the status of our service, you can execute:

sudo systemctl status hello.service

In general:

# Check status
sudo systemctl status hello.service

# Start service
sudo systemctl start hello.service

# Stop service
sudo systemctl stop hello.service

# Check service's log
sudo journalctl -f -u hello.service
  • It's not the best tutorial you have found. You should not create services in /lib/systemd/system/. This is reserved for the systemd operating system. For user defined services use /etc/systemd/system/ or much better let systemd do the right job with sudo systemctl --force --full edit hello.service to create the service and sudo systemctl --full edit hello.service to edit it. – Ingo Aug 31 at 17:45
  • @Ingo Thank you for comment. So you mean /etc/ is supposed to be where I can play with my files and services. Right, but I couldn't understand last two command. Could you tell me a bit more what is different from 'sudo systemctl start hello.service' and yours with '--force --full edit' ? – YJL Aug 31 at 20:09
  • systemctl start is to start a service, systemctl edit is to edit a Unit file of a service. Try it. Look with systemctl --help for options. – Ingo Aug 31 at 21:21
  • @Ingo Sadly, it seems fundamental problem hasn't fixed yet.I think it is nothing about different way of running script. Still device1/3 doesn't start properly.(I have no idea why it worked before), something prevent or overflow on GPIO while boot process so serial device gone frozen. – YJL Aug 31 at 22:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.