3

I’ve got a little program that uses an spi hat that I set to start running from rc.local.
It was all running fine under Jessie, but I’ve upgraded to Stretch and now it appears rc.local is being called before the /dev/spidev.* device files have been created, so the application fails to start. Once the login prompt appears I can start the app manually and the spi system works fine, so it just seams like a matter of timing and waiting for the spi dev files to be created.

I’m trying to work out what part of the boot process is creating the files in dev, so I can setup a systemd service that waits for them before starting my app. I have a working service that calls the app, but it’s having the same issue as rc.local and starting too early.

Anyone have any ideas or pointers as to where I should look?

Improve this question

2 Answers 2

Reset to default
1

rc.local is part of the old init which was made obsolete by systemd, introduced in Jessie.

systemd boot runs many processes in parallel, and the only way to manage these is with a systemd service which manages dependencies.

There is NO simple fix.

NOTE systemd attempts to run rc.local, but is only successful for simple tasks - it is best to avoid it.

Generally you should setup SPI devices in Device Tree.

You should ask a more specific question about the devices you are attempting to use.

Improve this answer
4
  • Ok that’s good to know, it’s just pure luck that it behaved nicely in Jessie then! I’ll start digging into device tree and see if I can force my app to start after /dev/spider.0.0 is available. I can do that in my apps code, but that feels like the wrong place to be doing those kind of checks.
    – nebulus
    Commented May 22, 2018 at 0:02
  • @nebulus you shouldn't need to "start digging into device tree" /boot/overlays/README documents a vast array of devices to include in config.txt
    – Milliways
    Commented May 22, 2018 at 0:21
  • When I said digging into I mean getting a better understanding of. I was under the impression that the spi system would start up in exactly the same way irrespective of if you have a device attached to it or not. Just checked and that appears to be the case, /dev/spidev0.0 is available after logging in whether I plug the spi device in at boot time or not.
    – nebulus
    Commented May 22, 2018 at 0:35
  • I assumed (probably incorrectly) that the spi system would be started by one of the systemd services, but it seams like it’s coming from one of the kernel threads, and so it’s possibly not possible to track when it’s running other than polling to find out when the /dev/spidev0.0 file comes into existence?
    – nebulus
    Commented May 22, 2018 at 0:38
1

It is difficult to give concrete advices with your only general information. The way to solve your problem is systemd. The old style SysV init system with rc.local is only emulated by systemd and it seems with higher versions of systemd the developer take less care of backward compatibility. I can understand this.

Polling for services isn't the right way to think. As already said systemd is working parallel. The order of execution of services at boot time is not defined! You only have to think in dependencies. A good entry to this issue is systemd bootup. For your problem with /dev/spidev.* is not available it may be good to start your program After=local-fs.target or After=.paths.target. After=basic.target is always a good general dependency. RequiresMountsFor=/dev/spidev or ConditionPathExists=/dev/spidev are also possibilities (see man systemd.unit). Look at the references for some examples.


references:
[1] Run script to setup Socks Proxy on Pi Startup
[2] Running a script after an internet connection is established
[3] Python script run from crontab does not recognize USB drive mounted later
[4] No access to USB port, when running python script on boot
[5] Python script does not run when called by service

Improve this answer
4
  • I fully understand that rc.local isn't the correct way and I've already tried to switch to using systemd style service to start the app, thats in place. The problem I have is really: What is it that is creating /dev/spidev0.0 ? As that is it what I need to make my service depend on.
    – nebulus
    Commented May 22, 2018 at 7:17
  • @nebulus I have just added some suggestions for dependencies to my answer. The best way ist to try.
    – Ingo
    Commented May 22, 2018 at 7:46
  • Getting closer! The ConditionPathExists=/dev/spidev0.0 feels like the right idea, but now it simply fails as that condition isn't met, really need a WaitForPathExists= ;)
    – nebulus
    Commented May 22, 2018 at 8:02
  • @nebulus Does my answer help you? Is it acceptable?
    – Ingo
    Commented May 26, 2018 at 7:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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