You are viewing paulmck

Previous Entry | Next Entry

And it used to be so simple...

  • Nov. 11th, 2011 at 10:12 AM
buggytux
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!

Tags:

Comments

( Read 7 comments )
Gustavo Sverzut Barbieri
Nov. 11th, 2011 07:35 pm (UTC)
It's just something you're not used to (aka: You're getting old ;-P)
Paul,

Sorry to tell you, but this is normal for people that go too deep into one thing and ends ignoring the evolution of the rest.

I'm more an userspace guy, that eventually have to do some kernel and I have the exact same surprises as you do... but with the kernel. OTOH, I'm helping systemd, then it's super simple and trivial to me ;-)

Anyway I have a hint for you, why not just use init=/bin/bash and start from there? If you can do whatever you need from inside the kernel with command line parameters, then you clearly can do it from bash as well, no?
| Frozen | Thread
paulmck
Nov. 11th, 2011 08:30 pm (UTC)
Re: It's just something you're not used to (aka: You're getting old ;-P)
Indeed I am getting old! Of course, so are you, but judging by your photo you aren't anywhere near as far along as I am. ;&ndash)

When I try your approach with qemu, I get a shell prompt on the console and no ability to interact with it. But then again, the point is to not need to interact with it. I tried init=/bin/mytest, where /bin/mytest was a script and got a system panic.

So, do I need to make a small C program that exec() the script in question? Or is there some other trick?
| Frozen | Parent | Thread
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 ;-)
| Frozen | Parent | Thread
paulmck
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! :–)
| Frozen | Parent | Thread
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:

http://cgit.freedesktop.org/systemd/tree/src/shutdown.c#n460

it's the reboot() syscall.
| Frozen | Parent | Thread
paulmck
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!
| Frozen | Parent | Thread
( Read 7 comments )