How are programs usually started in linux-based embedded systems?



  • Hello dear people,
    I try to find out how programs are usually started in embedded Linux-based devices. In addition to own considerations and web research i wanted to resolve this as a kind of expert interview to interview Linux experts. Maybe you can help me?

    The idea is to find the actually running programs statically in the file system or dynamically with tools. Therefore, I have to know in which ways these are started after booting. Of course, I have already done my first research. Please correct me:

    1.) Directly at / after booting: You adapt your own init start program, in which you start external programs. (Is this realistic?)

    2.) Autostart function of the respective distribution, usually in a special config file. Unfortunately very distribution specific. Example gnome-sessionproperties (Ubuntu, Mint) ... rc.local unter Debian... My question: Are there other standardized ways, especially in the embedded environment?

    3.) bashrc, is a configuration file of the bash, Entries are executed when the terminal is called. Since bash is under many Linux systems the standard shell, it is possibly a solution. However, the terminal must first be called, which does not happen automatically at system startup.

    4.)cron jobs.

    How is this usually done in embedded systems? Are there other ways that are possible? Many many thanks



  • Hello dear people,
    I try to find out how programs are usually started in embedded Linux-based devices. In addition to own considerations and web research i wanted to resolve this as a kind of expert interview to interview Linux experts. Maybe you can help me?

    The idea is to find the actually running programs statically in the file system or dynamically with tools. Therefore, I have to know in which ways these are started after booting. Of course, I have already done my first research. Please correct me:

    1.) Directly at / after booting: You adapt your own init start program, in which you start external programs. (Is this realistic?)

    2.) Autostart function of the respective distribution, usually in a special config file. Unfortunately very distribution specific. Example gnome-sessionproperties (Ubuntu, Mint) ... rc.local unter Debian... My question: Are there other standardized ways, especially in the embedded environment?

    3.) bashrc, is a configuration file of the bash, Entries are executed when the terminal is called. Since bash is under many Linux systems the standard shell, it is possibly a solution. However, the terminal must first be called, which does not happen automatically at system startup.

    4.)cron jobs.

    How is this usually done in embedded systems? Are there other ways that are possible? Many many thanks



  • Hi,

    all the running programs can usually be found by an ps aux for example during runtime.

    So far i dont see a reason for changing the init daemon or something else. These changes are possible, but much too complicated if you just want to know which processes are running on the system at the moment.

    Best regards,

    Andreas Klinger



  • First of all thank you for your response.

    For the context. I want to (Security-) test and fuzz embedded systems, there i need to extract the important programs. I want to write a tool that automatically analizes the filesystem of an firmware image and automatically tries to bring it up and running (qemu...) Then finds the important binaries in filesystem for other tests. So i want to anaylse the init process, the autostart config files, the cron job files etc, for the automatically started programs. I am very new to linux and try to use your expert knowledge to find the ways embedded linux systems start their software. So my question is: Have I forgotten an important start way? How are the important programs in such a system normally started?

    What would be the expected and normal way in such systems to start their main applications after boot?

    Thank you very much.
    Helmut


Log in to reply