The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---> On May 12, 2020, at 10:17 PM, Michael Jones <m...@meshplusplus.com> wrote: > > I've been investigating a problem with sysupgrade failing with the error > message "Failed to kill all processes", and then hanging indefinitely. > > This happens maybe once every 10-20 sysupgrades, and it's kind of a pain. > > So far I've determined this workflow that the sysupgrade command follows. > Note, I'm not aiming for 100% accuracy, but just broad strokes. > > > 1) /sbin/sysupgrade locates the file to upgrade from on the filesystem, or if > the second option to sysupgrade starts with http://, it downloads the > firmware file using wget. > 2) /sbn/sysupgrade does some minor validation of various things, and grabs > whatever config files it thinks the end user wants to be restored and packs > them up into some kind of tarball. > 3) sysupgrade sends a message, via ubus, to procd, to initiate the upgrade. > 4) Procd does some stuff which I haven't finished completely understanding > just yet, but it looks like firmware verification to make sure we don't > upgrade to a bad firmware file. > 5) It *does not* appear that procd will proactively terminate services until > everything (or almost everything) is shut down. Seems like something that > should be added to increase reliability. > 6) procd replaces itself (execvp systemcall) with the program /sbin/upgraded. > This means that procd is *no longer running*, PID 1 is now /sbin/upgraded. So > service management is not possible at this point. > 7) /sbin/upgraded now acts as PID1. It executes the shell script > /lib/upgrade/stage2 with parameters. > 8) The shell script loops on all processes, and sends them the TERM signal, > and then the KILL signal. See email subjec for problems with this. > 9) the shell script creates a new ram filesystem, mounts it, then copies over > a very small set of binaries into it. > 10) The shell script changes root into the new ram filesystem > 11) Inside the ramfilesystem, the shell script writes the upgraded firmware > and saved configuration to disk > 12) Reboot. I’ve had many problems with ’sysupgrade’, since the CPU/machine is my own board. For the longest time I was able to crib from a TP Link model that had a similar processor and memory setup. Not so now. The documentation for integrating one’s ‘custom’ board into the sysupgrade ’standard’ is severely lacking. I didn’t find the ‘validation’ checks ‘minor’ as in where they occurred, and how to generate them in the build. It took a while to find ‘fwtool’ and another while to realize perhaps I’d just dump the whole thing, and substitute ’sysupgrade’ with a mid … to the devices. But of course, that has the problem of how to deal with programs active, that may cause fatal errors to occur, when one is replacing the underlying ‘rom’ image… As for why things don’t shutdown when receiving a ‘kill -9’ signal… there are low level kernel activities that may be in an uninterruptible ’state’ waiting for events to occur to continue, which never occur, and cause the program to not exit cleanly. I’ve never had this problem with ‘reboot’, but there doesn’t seem to be a really nice way to ‘reboot into a firmware upgrade initram image’, do the work, then reboot with new firmware. The copy to Ramdisk a set of required programs, chroot, then do the work, seems like it has many potential places to fail. As it is I’ll slog through what I need to do to support sysupgrade for my product in the field, but it’s not because the documentation is available, completely, or easy. John Clark. >
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
