Solved pkg killed it self twice, once because no internet, the second time reason unknown

I'm very tired of these assumptions : why should it be clear for me, I mean it's clear that it wasn't because I didn't interpret it. Is it so difficult to just explain things rather than boasting like that and make one feel like he is a complete idiot? What is so difficult in saying to someone that the phrase there mean that you went out of ram and the system just started to randomly close process ?
The original thread title and the tone used in the text weren't all that "friendly." I think the tone of conversations on this forum has gotten a bit more heated lately, especially among those new to FreeBSD. In my opinion, a little respect is needed for those trying to help, who, in most cases, are highly experienced users of this and other operating systems. No offense, this is just what I see.
 
I was just checking the log because so far the only thing I did with the log is to grep the uninstalled package. But looking at the log I see, and I remember that on October 7 I did upgrade pkg is version, minimize the windows I forgot it and later disconnect the internet and at around 3 am that night pkg killed itself, the next day, I connect to the session and re-run pkg update and at one point it killed itself again but don't know why, and without me noticing, I tough the upgrade was finish, so I reboot. Re-run the command pkg update upgrade and reboot again, that's when I noticed that packages were missing.
Most programs are *not* bulletproof against every conceivable thing going wrong and *will* misbehave if something they rely on goes wrong. This is what happened here. You disconnected the internet without checking what was happening with pkg, then your system ran out of memory and pkg got killed, then you ran pkg update without repairing what might have broken due to earlier problems and so on.

You can't expect an open source OS mostly run with volunteers to be as bulletproof as commercial OSes (and even those are not all that bulletproof). Instead of blaming pkg and complaining here about how pkg-2.3.1 is untrustworthy, it would have been better if you had just said "here is what happened and how do I recover from this?".
 
I'm very tired of these assumptions : why should it be clear for me, I mean it's clear that it wasn't because I didn't interpret it. Is it so difficult to just explain things rather than boasting like that and make one feel like he is a complete idiot? What is so difficult in saying to someone that the phrase there mean that you went out of ram and the system just started to randomly close process ?

Well, but you on the other hand should have posted the log in the first place. Instead you just made a fuzz with "killed itself twice" with no further forensics.
 
Ironically, I'm probably on the OP's ignore list, but in this case, I'm going to say I think they're right about a lot of this. We tend to make assumptions, and even when we don't mean to, we tend to, instead of saying, Thiis is what you should do, say, Well if you'd done this, maybe we could have helped. I remember an old mailing list letter that I still have saved, where someone said something like (I said saved somewhere, not sure where, and this isn't important enough to dig it up), to say enable <whatever> with no further explation is almost no help at all. I feel like I started the heating of this thread with a somewhat nasty comment about the posting style, but leaving that aside, I can understand the OP's frustration when someone give an answer that is easy for the person that gave the answer, but not so simple to person who reads the answer.

I can give an example, on an old FreeBSD mailing list thread, someone gave a solution. Let's say, (I'm going on poor memory here) they said something like download the tarball and patch the files. So, that is simple advice for many of us, but at the time, I didn't get it and asked them. They didn't say man tar, man patch, they were nice enough to say download the file, then run tar xvf filetobepatched.tgz. Then download filefix.patch, then run patch filetobepatched < filefix.patch. I've never forgotten how nice so many people were to me as I was learning and I try, when I can to give the same courtesy, and if someone doesn't understand an instruction I give, I try to clarify, to pass it forward, so to speak. Not that I have great advice, but when I do know how to something, I'll try to share it.

So, I think the OP had some reasons to be irked, and many of us, especially me with my nasty remark, didn't help the OP's mood, and then when one of us tried to help with something that wasn't clear, it ran to more frustration. Was this ideal? I'm not any kind of judge of human nature, so I dunno. Maybe, they should have reacted by saying, I don't get it, would you explain what you meant by this? Anyway, it's up to each of us to decide how to react when we get an answer that doesn't help, as well as up to each of us to decided how much detail to put in an answer we give.

TLDR: What is simple to one person might be complex to the next one. Many of us know, for example, how to use bectl or beadm to make a boot environment, but if you don't know it, and someone just says, why don't you make a backup BE before the upgrade, that would probably frustrate the person with the question, who hasn't learned about BE's
 
Well, it is also a good idea to follow syslog so that you see kernel messages.

In the case of an out-of-memory error you get a better error message than from the program's stderr.

DEs should make that easy.
 
Back
Top