1

I understand that the init process is the first to run and all processes get launched from it, but is it possible to launch any programs before init? (Possibly writing a kernel driver that gets executed early on in the boot sequence?)

This program would be testing various parts of its own hardware and writing a text file to the root file system relaying its status. If launching a program during the boot sequence is possible, what is the best way to go about doing this given that the program I'm executing must happen after the hardware its checking has already been initialized earlier in the boot?

I am looking to launch this program after a couple seconds of the computer turning on while the entire system takes about 13 seconds to fully boot. This is necessary as the application is catered towards radiation testing. During radiation testing, there are pulses from the beam showering the computer in heavy ions, protons, neutrons, etc. and those pulses are a couple seconds apart. I need to launch a program before the beam comes back on and potentially crashes the computer causing another reboot.

  • You should tell us which version of ubuntu you are using, as older versions use upstart and newer ones use systemd. In either case you should be able to get a user space program launched within a second of the linux kernel starting as long as it is not depending on things like the network or graphics being available. – icarus Jan 13 '17 at 4:30
  • I am using Embedded Linux for arm. I am using yocto to create my image and am using uboot as the bootloader. I guess the distribution would be poky. – AustinTronics Jan 13 '17 at 4:43
  • Ah, I was misled by the ubuntu tag. Minimal research suggests that yocto uses sysv init by default. yoctoproject.org/docs/1.6/dev-manual/… but others are easy to use in their place. thelins.se/johan/blog/2014/06/yocto-part-i-baseline-boot-time might also be helpful. – icarus Jan 13 '17 at 4:57
  • 1
    To almost directly answer your question, no you can't start anything in user space before process number 1. Every process is created by the fork or clone system calls except process number 1. The systemd/sysvinit question is which one you have as process 1, which can launch your user space program soonest after the kernel has created process number 1 by magic. If you really want fast startup of something then you could create a tiny program to have as process number 1. It would fork, and then process number 2 could exec your monitoring program, leaving process 1 to exec systemd/sysv. – icarus Jan 13 '17 at 7:16
  • 1
    Yes systemd (well part of systemd) is a suitable program for PID 1. PID1 is launched pretty much as soon as the root filesytem is mounted. Hardware init has already been done. The tiny program you write is user space, and does not go in the kernel. In general I would suggest trying to see how fast you can launch from systemd units or /etc/inittab before writing the 8 line C program. I don't have any resources at my fingertips. – icarus Jan 13 '17 at 7:51
3

There are ways to do this, but....

Don't do that.

If you have a safety application, do not rely exclusively on a linux based machine to control it. You really should have some sort of HW based watchdog to manage this for you.

Please.

  • 1
    I wish I had more than one upvote to give you for this. – Wildcard Jan 13 '17 at 4:50
  • No worries, what I'm working on is more R&D than anything. My application is not intended for life-critical applications. But similar to what you said, I do have external radiation hardened hardware running bare-metal code babysitting the computer I'm doing radiation testing on. The question is...how much babysitting must it do. I'm trying to characterize Linux as a potential candidate for space applications so I must gather as much radiation data as possible, hence running special programs at boot to characterize the boot process in space. – AustinTronics Jan 13 '17 at 5:48
  • OK, so you already have some dedicated HW to watch things. I would still strongly caution against requiring the boot process to complete in 'X' time. The system (linux) was NEVER designed for this. If you are going to sample boot time 'X' give yourself a very conservative 5 to 10x safety factor. Cheers and GL. – Stephen Rauch Jan 13 '17 at 6:06
1

If I understand you well, your computer is unable to boot because of beams of radiations that occur periodically and you want to start your computer between two of these events in order to proceed to a check. So, it does not matter that your computer eventually boots, right?

You can do that:

  • build a static program (i.e. linked statically, no dependencies to libraries on the disk)
  • put it on your initrd image
  • at the Linux boot prompt (use the grub menu to change it), add init=/path/to/your/program

Your program will start instead of the standard init, so your machine won't boot any further, but your program will run.

I hope you don't need anything provided by a standard Linux installation (mount points other than /, daemons, remote access, serial console, etc) because you won't have any of this of course since your system didn't start at all.

Note that if you need your machine to boot normally after your code has run, you can probably exec /sbin/init as a last instruction.

  • Not quite. The computer is not that soft to radiation; it usually can go a few rounds with the beam before something fatal happens causing the computer to reboot. However, just because the computer can stay up doesn't mean all hardware is not affected by radiation. There may be bits that flip in memory (Single Event Upsets) causing certain hardware to fail but the computer to still remain functional. My program monitors several pieces of hardware on the computer to see what exactly has failed and how. If my program is not running when the beam is on I cant monitor the hardware effectively. – AustinTronics Jan 13 '17 at 4:04
  • @AustinTronics Not sure I understand: your machine must boot? your program must run while the machine is functioning regularly? Or would my proposal to substitute init with your diagnostic program be ok? – xhienne Jan 13 '17 at 4:17
  • I need my program to run during boot in order to monitor hardware as soon as possible, but the system must also boot as normal to continue monitoring that hardware under standard conditions. – AustinTronics Jan 13 '17 at 4:29
  • As for executing sbin/init after following your steps, don't know if that will work. Im not quite using ubuntu and therefore don't have grub. I'm actually using uboot and built my own root file system using yocto for Linux 3. – AustinTronics Jan 13 '17 at 4:39
  • @AustinTronics grub doesn't matter actually. All boot systems are the same for that matter: there is somewhere a Linux command line that is embedded and that you must change. As for exec'ing /sbin/init at the end of your program, I've never done that but it probably would work. You can test this in 1h with an hello-world prog. On the other end, I suggested this as a quick fix. A more durable solution would be to reconfigure your OS so that init executes your program first. Before or after init would not make a big difference. – xhienne Jan 13 '17 at 9:13

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.