How to start application on imx6

I’ve figured out how I can create a service using systemd to automatically start my application when the unit boots up by manually executing a systemctl command to set it up to do so. While this is ok in a development environment, doing this manually on units that have already been shipped to customers won’t work for us.

Here’s a quick overview of our architecture. The imx6 is being used for a Local Operator Interface for an instrument. The only connection this module has with the “outside world” is a private TCP/IP connection with the instrument. When we need to upgrade the firmware, whether the bootloader, kernel, file system, Qt libraries, or our application, our PC software sends the file(s) to the instrument, which in turn will FTP them to the imx6. On the imx6, we’ll be running a separate upgrade task that looks for and processes these updates.

It looks like everything should work well enough for upgrading our application and/or the Qt libraries. However, my concern is when we have to upgrade things like the kernel and/or file system. I’m guessing that when one or both of the above are replaced with new versions, the service we initially set up using systemctl in the factory will no longer be recognized, maintained, saved, or whatever the appropriate verbiage would be. In other words, after such an upgrade, the imx6 would start up WITHOUT running our application. Assuming this is correct, how can I get around it? Having the customer disassemble the LOI, hook up additional hardware, and manually go in and try to run systemctl is obviously not an acceptable answer. It’s equally unacceptable to send out a field service tech to do it or to replace the SoM. Is there some way to reconfigure systemd such that this would be integrated into it? Or would I need to make modifications to the kernel itself in order to facilitate this?

Thanks in advance to anyone who can point me in the right direction.

Dear @KingGrunt

I don’t know if I understand you’re request correctly. If you have a systemd servcie you basically say which application needs to be started. As long as this name stays the same the application should start again. I assume you enable the service with "systemctl enable " name? This will basically just create a link under /etc/systemd/system/.wants/.service. Systemd will start all services that have a link in such a target.wants directory. So as long as you don’t delete this links you are safe. The kernel does not have any influence on which application will start when.

Regards,
Stefan

Stefan,

Thanks for the quick response. I wasn’t sure how the “systemctl enable” persisted, but you answered that question for me. And once I’ve set up a unit with our service enabled in that manner, it seems to work as expected. My question, though, is about what we do in the future - i.e. on units that have already been installed on a customer sites - and there’s a need to upgrade the kernel and/or the root file system. Based on your answer, I would assume that the link would be destroyed when the root file system is updated (i.e. replaced). But with that said, would it be possible to tweak the new root file system by hand? For instance, could I untar it, create the “.wants/.service” link by hand (perhaps even a direct copy of the one created through systemctl), and retar it such that the link would exist when the new root file system is installed? If so, that would make for a clean solution from the customers’ perspective.

Hi @KingGrunt

How do you create your Filesystem update? How do you handle the update (two partitions?)? Why do you not simply include the enabled service in your update? Then if you install the new Filesystem the links are already there and it will automatically start the service again. It’s also easier for testing, if you have a complete image it’s much easier to test and afterwards deploy it.

Regards,
Stefan

Stefan,

For right now (we’re still in the early development stage of the LOI part of the project), I’m using TFTP to send the entire package that was generated by building the Toradex distro to the bootloader. The details of how I’ll ultimately package and distribute the file system, kernel, etc. are still to be worked out, but I’m hoping to send a zipped up version (.tgz) of each component (i.e. the root file system in this case) and have them extracted on the target by a “firmware upgrade” task. With that said, it sounds like you’re telling me that I can do exactly what I was hoping to be able to do - create the soft link by hand in the file system (using “ln”, I assume) - which at least in my case appears to get created in the “/etc/systemd/system/multi-user.target.wants” directory, and package it up for distribution. Is this correct?

Thanks again,
KingGrunt

Hi @KingGrunt

Perfect, good to hear that you already build the BSP yourself.

The best would be if you add a new recipe in your own meta layer which provides the service file or even the whole application including the service file. In the yocto mega manual chapter 26.127 you can find some information:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#using-systemd-exclusively

Here we tried to describe how you can add your own meta layer:
https://developer.toradex.com/knowledge-base/hello-world-integration-into-openembedded

Please note that you would have to add a service file to the hello world application which is your systemd service file.

If you do all of this your image will automatically include the link to /etc/systemd/system/… as well as your application.

Regards,
Stefan