Running smxi -G as root in konsole terminal.
It does an apt-get update, then says:
and hangs after that. Gave it several minutes then aborted.
Log file uploaded at paste.debian.net/122499

inxi output:

Back to top

The logs show smxi stopping after the kernel version is calculated, so that's not actually where it is stopped, I tested it a few times and everything seems normal.

This type of hang might be a networking issue, or it could be some error in the smxi code that is only triggering on your system, the usual cause of a total hang is forgetting to give grep something to parse, then it just sits there, but usually I'd see that.

The actual halt is here:


And specifically, in terms of logic, here's the only place I can see any possible hang:



but that would be weird, I've never seen that hang.

Since I'm not seeing obvious places, take a look in dmesg for kernel oops or something like that, look in df -hT

After that there's not a lot to look for.
Back to top

As you mentioned network issues, I checked that NFS mounts and such like were all in place, and tried again. It got a little further, i.e. an error message instead of a hang:


So maybe the 'weird' place, which involves awk, is it.
Back to top

df -h -T | grep -E '(/|/boot|/var|/home)$' | S=${S} C=${C} awk '{print $NF, ENVIRON["S"]" - ", "Type:"ENVIRON["C"], $(NF-5), ENVIRON["S"]"Size:"ENVIRON["C"], $(NF-4), ENVIRON["S"]"Used:"ENVIRON["C"], $(NF-3), ENVIRON["S"]"("ENVIRON["C"], $(NF-1), ENVIRON["S"]")", "Free:"ENVIRON["C"], $(NF-2)}'

the idea is that you copy that and run it to see if it manifests an error.

If so, that would be a first, although I can think of a case where it might.

Also show plain: df -hT

none of this logic has changed at all for years now, the code hasn't either.

Take a look at the log each time you see an error, and paste in here the last 10 lines or so of it, that's all I actually need to see.
Back to top

Well, it's a first! ;-)

df outputs long filesystem names on a line by themselves. I have several CIFS and NFS mounts, and they tend to have much longer than average names, e.g. "abcdefgh:/media/dvdram". That of course upsets awk.

Possible fixes: df option -P forces output on a single line; I don't know how portable that flag is. Or of course the awk script could take account of it, though that could make it rather cumbersome.

So the original "hang" that I reported was probably due to waiting for a CIFS or NFS device to come online. The real error was the awk barf.

Thanks for the help; I can at least run smxi now I know what to watch for.
Back to top

I'm not going to ask this again:

Please post the data I requested.

df -hT

If you don't post this data, I'm ending this support now.

Nothing is a bigger waste of time than you posting describing data that you are not pasting here for debugging.

Run the command: df -hT
or better yet, so I get the true structure, run this command:
cd && df -hT > dfht.txt
then use paste.debian.net to upload that exact file, using the file upload option, from your user home directory.

We can either solve this problem, or not, but talking about something that requires hard data is not solving it.

So please do not respond to this again until you have provided the data required.

I'm familiar with wrapping df output lines, but I refuse to waste my time inventing such output when you could simply provide it in a few seconds of your time. So read what I write and do as requested, or just leave me alone. Sorry to be brusk, but I clearly asked you to post this data, which is required to fix the problem, and you have now ignored that request totally, as if I hadn't even said it, which makes me unwilling to waste more of my time on this.

With that data, I can inject it directly into my local smxi, debug the problem, and be on my way within a few minutes. Without it, we're just wasting time, not fixing the issue for everyone else, and engaging in totally non productive effort. What's wrong with that picture?
Back to top

Wow! It must have taken you ages to type all that! ;-)
But anyway, here is the df -hT output you asked for:

The problem happens when the CIFS mounts are (a) long and (b) end in a / character, which they all do.

One fix (that works on my system) is to use 'df -hTP'. Another is to ignore the lines with the filesystem names on, since they are of no interest anyway:

But of course you may have other considerations of which I know nothing.
Back to top

that's better, the second option looks best to me, thanks.
Back to top

This is now corrected, I still cannot understand why the script hangs there for you however, awk should just give an error and go on, but it is what it is, maybe a new awk behavior has crept in?

Here's the patched, more robust, solution:


Back to top

I've noticed the system hanging on occasion when it's wanting to access an NFS or CIFS mount whose server is not yet ready. There is a -l flag for df which limits the output to local filesystems; that might be appropriate here.
Back to top