Log in

No account? Create an account

Previous Entry | Next Entry

And it used to be so simple...

It is something I have done many times under many different operating systems. You write something into the startup scripts, take the system down, then regain control at startup. So I planned to take this approach for my KVM-based rcutorture setup: Mount the image file, deposit a test script in the startup scripts, unmount the image file, start qemu, then analyze the results (either deposited in the filesystem or dumped to the console). What could be easier?

So I manually mounted the file I use as the qemu disk image, my plan being to manually create simple tests as a first step towards automation.

Hmmm... Everything looks very strange and unfamiliar. Ah, yes, this is upstart. No problem, the Internet is but a mouse-click away, right? But wait, the documentation says that upstart and the more-familiar (to old guys like myself, anyway) sysvinit can co-exist on the same system. And what about this new systemd thing that I keep hearing about?

So my tests are going to have to inspect the filesystem and figure out which of these three things is installed. And maybe someone installed one of them, then switched to the other, leaving traces of their earlier choice lying around. How is my script supposed to figure all that out? Of course, if it was just me running the tests, I could simply make sure that a pre-selected boot-up mechanism was installed. But that is silly — anyone anywhere should be able to test RCU. So I need to be able to deal with any of the three boot-up mechanisms. But wait, it is far worse than that: What is my script supposed to do when someone else comes up with a fourth, fifth, or sixth boot-up mechanism? Ouch!!!

It is clearly time to just say “no”! After all, my main test (rcutorture) is coded in the kernel, so it is clearly going to be far easier to translate my driver scripts to Linux kernel code than to code up a script that can outwit all present and future perpetrators of bootup mechanisms. In-kernel coding will allow me to fully control the test using kernel boot parameters, and thus happily ignore which of sysvinit, upstart, systemd, or whatever is installed. Some times you just have to get a horse!



Gustavo Sverzut Barbieri
Nov. 11th, 2011 08:39 pm (UTC)
Re: It's just something you're not used to (aka: You're getting old ;-P)
being PID1 will imply some problems, you can't be a script and you can't return/exit otherwise it will panic.

It's strange that bash did not work, I use it to rescue my system whenever I break systemd in development ;-) But it's not qemu.

Have you tried busybox? It ships with simple old-fashioned script that uses only initab (that can be mostly empty).

Otherwise just go with that approach of a C app, but likely exec() will not be good, just fork+exec+waitpid or call system().

PS: Indeed I'm not as old, 29yo. I have my years to learn and become great ;-)
Nov. 11th, 2011 08:47 pm (UTC)
Re: It's just something you're not used to (aka: You're getting old ;-P)
And it turned out that the script really does work, at least if you remember to do chmod +x /mnt/bin/mytestshutdown -h now doesn't shut down the system. In contrast, if I boot the system normally and log in, shutdown -h now shuts down the kernel and causes qemu to exit normally.

PS: And I do wish you the very best of success in the 24 years you have to catch up with my current age! :–)
Gustavo Sverzut Barbieri
Nov. 11th, 2011 08:55 pm (UTC)
Re: It's just something you're not used to (aka: You're getting old ;-P)
AFAIR shutdown will not work as it would talk to PID1 so it would call the correct functions to turn off the system. You can create a program that you exec and it does the work:


it's the reboot() syscall.
Nov. 11th, 2011 09:35 pm (UTC)
Re: It's just something you're not used to (aka: You're getting old ;-P)
Ah, good point. Arnd Bergmann suggested using /sbin/poweroff --force which does the trick.

Thank you again for your explanations!