1

I'm making a opkg package for a software update.

This package require a reboot after installation and needs some work done after the next reboot.

I added a shutdown -h now in postinst script but it seems to shutdown too early and interrupts the opkg install command.

Then the opkg system won't have the package info recorded, like opkg list-installed won't list the package as installed.

So the problem I'm trying to solve is: how to reliably schedule a shutdown/reboot in postinst script of OPKG package?

But I guess the fundamental question is, how to schedule a task in a shell script that runs as soon as the all the ancestors of current shell die, but not sooner than that?

Reference: What's postinst script and opkg package management system

  • Do you mean ancestors or descendants? Pid 1 is the ancestor of all processes, and it never exits. – Mark Plotnick Mar 23 '16 at 00:23
  • @MarkPlotnick My understanding to this specific problem is, ipkg install calls ipkg configure, ipkg configure calls postinst, postinst calls shutdown -h now. I want to schedule to shutdown to after ipkg install finishes. Currently I can do nohup sleep 5 && shutdown -h now & in postinst assuming 5 seconds is long enough for everything to finish, but really not sure. – user3528438 Mar 23 '16 at 00:56

1 Answers1

1

The problem is ill-defined. If you follow the chain of processes from child to parent, you'll eventually reach process 1 (init). When it dies, it means the system is rebooting.

Rebooting a machine is not something that's normally done as part of an upgrade because only the administrator knows when it's safe to reboot. Rebooting during an upgrade is definitely not safe. (Yes, Windows does it, and it's a shining example of what not to do — many Windows users have horror stories of lost work because of forced upgrades causing reboots.)

If the upgrade is attended, show the administrator a message telling them to reboot as soon as possible.

If the upgrade is not attended, then have your automatic upgrade system arrange the reboot. Only your upgrade system knows the particular circumstances that make it safe to reboot at a certain time — because you've activated the failover on your server, or because the production line that your embedded device controls is stopped. Your upgrade system runs opkg, and then checks whether an upgrade is needed; for example, it might reboot (when it's safe) if a file /reboot_needed exists.

  • I have to admit the problem is so ill-formed. Full story: the target I'm working with uses OPKG as upgrade package, which meets the requirement when it only requires userspace application. At the second release features bloat so hard that uboot, kernel, a few daemons, and an attached storage medium's partition table and partition table format all need to change and my solution was to depend on postinst script, which turned out to have ton of problems and is impossible to get to work reliably. – user3528438 Mar 24 '16 at 00:42