On Friday 06 September 2019 16:37:48 Gene Heskett wrote: > On Friday 06 September 2019 14:26:25 Nathan Stratton Treadway wrote: > > On Fri, Sep 06, 2019 at 13:07:55 -0400, Gene Heskett wrote: > > > Humm, so why does amanda crash the debian version of buster, but > > > not the raspian's (jessie, stretch) that preceded it? And crashed > > > the armbian on a rock64, supposedly stretch based? Gotta be > > > something different, > > > > I would be very surprised if usrmerge has anything to do with full > > system crashes. > > > > You might have better luck tracking this down in a rpi-related forum > > -- from what you have posted Amanda does seem to be triggering it, > > but Amanda isn't doing anything "unusual" that should be able to > > trigger a hardware/system crash, so almost certainly there's a more > > general hardware or OS problem which Amanda is tickling somehow. > > > > > > I don't have any personal experience rpi systems, but off hand a few > > possible crash triggers would be > > * high network usage causes network interface to die > > * high disk I/O causes failure of some disk device or data bus > > * high CPU usage causes temperature to exceed max-temp threshold > > and triggers shutdown > > * high something/combination-of-things exceeds available power > > budget of system > > > > To differentiate some of these possibilities you would need to watch > > the system while Amanda started up and see if there were any signs > > of individual components failing first. Also, watch "top" and > > similar monitoring utilities on the system while Amanda starts up to > > see what actually going on right then. (But, again, rpi-specific > > forums would probably have more useful advice.) > > > > As far as Amanda-centric testing, you could try running dumps of > > just one DLE at at time, to see if the crash is consistent > > independent of the DLEs or only happens for specific ones. > > > > Also, you could pull the "tar" and "gzip" commands out of the Amanda > > client debug files and run them manually (directing output either to > > /dev/null or to a network pipe to another system) to see if you can > > identify which specific command triggers the crash. > > > > > I just spent an hour looking at picnc's /var/log/amanda stuff, > > > nothing looks out of place. So now I am puzzled for sure. > > > > (Did you check /var/log/kern.log or /var/log/syslog ?) > > syslog is clean. I don't see anything obviously sick in kern.log. > Thanks Nathan. > > > Nathan
i interchanged the order, so /boot was first and removed those dle's that weren't mounted. Same story, dead the second amanda touched it. Now, possibly an answer. That install is an arm64 install, not an armhf. Armhf uses u-boot, whereas arm64 uses grub. I've prepared an arm64 net install for the rpi-4b, might have enough roubd tuit to get that done today. If when amanda touches it, it dies too, then I will re-install, using the armhf version. Maybe theres something in amanda that demands armhf. But arm64, using grub to boot is enough of an advantage simply because I can build and install my own realtime kernels 10,000% easier. u-boot, makes switching kernels a pain in the ass. There is also another possibility, building amanda on the arm64, as opposed to using the common and clients debs from the repo. I have NDI which the repo versions are built for. AHA!!!!! Maybe this is a clue, I had three ssh -Y sessions running into that machine before amanda ran. Two of then lost route to host, as expected for a crash, but the third was running a sudo -i (root) shell, and it logged this: ------------------ root@picnc:/usr/local/etc# ls (I expected that to be empty, it was, and I left it there for the night) root@picnc:/usr/local/etc# Broadcast message from systemd-journald@picnc (Sat 2019-09-07 02:04:29 EDT): systemd[1]: Caught <BUS>, dumped core as pid 3974. Broadcast message from systemd-journald@picnc (Sat 2019-09-07 02:04:29 EDT): systemd[1]: Freezing execution. --------------- Thats all it logged. Note time, amanda was started by cron at MAILTO=gene # m h dom mon dow command 01 2 * * * /GenesAmandaHelper-0.61/backup.sh Daily 2:01 am So 2:04:29 would have been about the time the estimates were in and the actual backup stuff started. This should be a clue, when I go out and power cycle it to reboot, I'll see if I can find that core dump and preserve it. The question then is what do I do with it? Can gdb look at it? A whole bunch of questions re territory I've never walked on. So I'm clueless, so use my hands for a remote control like I've done so many times when a transmitter is off the air in Iron Mountain MI and I'm 950 miles away at home in WV, and the only hands I have are on the girl on the far end of a phone line, and who just barely knows where the light switches are. We at least are not dealing with lethal voltages here. There, thats the first thing I have to think about. :-( Thanks. Copyright 2019 by Maurice E. Heskett Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
