X1000 occassional hanging (SOLVED)

	Bottom Previous Topic Next Topic
Register To Post

« 1 (2)

Anonymous

Re: X1000 occassional hanging

#21

@rjd324

Hmm, i remembered something...there was a system program stalling the boot a while back in certain circumstances (since then fixed).

Iirc it was the date command together with the SERVER switch to pull the current time from a timeserver address.
I can see that you don't use that, but TimeGuard instead...who knows, maybe it suffers from a similar problem?
So my guess would be to shut down TimeGuard first and go from there.

nbache

Re: X1000 occassional hanging

Posted on: 2022/1/2 22:26 #22

Just can't stay away

And at any rate, I assume TimeGuard also needs the network to be up and running, so I'd recommend not starting it from WBStartup, but instead from Network-Startup. You could e.g. put a "Wait 5 SECS" (adjust if needed) after the "; Add below this line applications that need a running network" comment line, and then start TimeGuard - if it must run from WB, start it with WBRun. Also, if it needs it, CD to its program dir before WBRunning it, and back again afterwards (just in case you add other stuff later).

This is the reason there is a Network-Startup script: To start stuff that wants a network.

Best regards,

Niels

rjd324

Re: X1000 occassional hanging

Posted on: 2022/1/2 23:00 #23

Quite a regular

I have hacked in some debugging into my SS.

Let me continue using my X1000 as usual and let's see what I get during the SS on a cold boot after leaving it all night. I will update the thread in due course.

@nbache
Earlier you said that you still have this problem that I reported (or a similar problem). Is that still the case, or did you somehow fix it?

nbache

Re: X1000 occassional hanging

Posted on: 2022/1/2 23:27 #24

Just can't stay away

@rjd324

No, mine is not fixed. But I'm not convinced it's the same thing. Anyway, we'll see if your debug output gives more clues.

Best regards,

Niels

Anonymous

Re: X1000 occassional hanging

#25

@nbache

Quote:

This is the reason there is a Network-Startup script: To start stuff that wants a network.

It doesn't work that well, though.

The network-startup "script" in it's original form does nothing else than
Quote:

AddNetInterface QUIET DEVS:NetInterfaces/~(#?.info)

wait for the network driver to be loaded, but *not* for the network to be *up*.

You can check that with any script that access a website.

e.g. i'm starting three arexx scripts in my network-startup *after* the above line, all of them either access a website or an address on my local home network.
While latter works, the website wasn't reachable in 3 out of 10 cases and eventually stalled the whole boot process where either the mouse was in busy state forever, i couldn't access certain directories, programs would not start, etc. (believe me, i was furiously searching for the bug in my script until i planted some debug output and realized it was locking up due to not being able to access the site in the first place).

What i did, and what fixed *all* of my startup problems (except the occasional machine exceptions coming from the gfx board, was to add a failsafe to one of my scripts *right* after th above line.


/*

Checking for up and running network.

*/

v_network=0

v_network_retries=0



DO WHILE v_network=0

    ADDRESS COMMAND 'ping -q -c 3 192.168.178.1 >T:boot_ping.log'

    OPEN(pl,'T:boot_ping.log','R')

    DO WHILE ~EOF(pl)

        v_ping=READLN(pl)

        IF INDEX(v_ping,'loss')>0 THEN DO

            v_loss=COMPRESS(SUBWORD(v_ping,7,1),'%')

            LEAVE

        END

    END

    CLOSE(pl)

    IF v_network_retries>2 THEN DO

        ADDRESS COMMAND 'SAY ERROR: could not connect'

        IF EXISTS('T:boot_ping.log') THEN

            ADDRESS COMMAND 'delete quiet T:boot_ping.log'

        EXIT 0

    END

    IF v_loss=0 THEN

        v_network=1

    ADDRESS COMMAND 'wait 1'

END

This checks and keeps the scripts from starting unless the internet is *really* accessable.

Time loss is 10 seconds at most, 4 seconds normally (but it's not feelable since the system is not yet up for usage after this short amount of time anyway).
After three unsuccessful tries it stops, exits the scripts and gives control back to the system.

As i said, after planting this, i *never* had a WB boot stalling ever again.

...and i faintly remember i told that on the Hyperion forums now too...ah well

rjd324

Re: X1000 occassional hanging

Posted on: 2022/1/3 8:08 #26

Quite a regular

@Raziel
Very useful to know. Why were you keeping this information from us? Tehe.

This is something to consider also.

nbache

Re: X1000 occassional hanging

Posted on: 2022/1/3 23:16 #27

Just can't stay away

@Raziel

Yes, you are of course right, there isn't any check in the script per default.

Usually, you can just get away with the Wait I mentioned earlier, but of course it's still no guarantee.

Your solution is much more failsafe, but also rather complicated.

What I do, and what normally serves me well, is I have the following lines in my Network-Startup after the AddNetInterface:

---8<---
Wait 5 SECS

GetNetStatus CHECK INTERFACES,RESOLVER,DEFAULTROUTE
If WARN
Wait 3 ; Increase chances of IPrefs having opened the final WB screen
RequestChoice "Network Startup" "Network not operational,*nS:Network-Startup aborted" "OK"
Quit
EndIf
---8<---

It's still not perfect; I remember Olaf saying something about GetNetStatus not always being able to determine for sure if things were up, but it's at least more concise and actually mostly works.

Maybe a matter of taste (and network conditions).

BTW, when you write about giving control back to the system, don't forget that Network-Startup is already being executed asynchronously, so in effect you're just exiting it, the system already has control and proceeds to boot WB while we start the network (which is why starting network-demanding programs from WBStartup is not such a great idea, as mentioned above).

Best regards,

Niels

Anonymous

Re: X1000 occassional hanging

#28

@nbache

Quote:

BTW, when you write about giving control back to the system, don't forget that Network-Startup is already being executed asynchronously, so in effect you're just exiting it, the system already has control and proceeds to boot WB while we start the network (which is why starting network-demanding programs from WBStartup is not such a great idea, as mentioned above).

Oh, no, wait a second.
That script i posted is part of any script that needs access, it's nothing that is used on it's own.

"Giving control back to the system" means, that i exit the script that fails to access the internet, if no network can be found or not internet access is possible (after the three tries and for whatever reason), which means the script in question can't stall the boot afterwards any further.

The script is not running after that, of course, but since i also keep a boot.log (which every script writes to during boot) i can see what went wrong after WB is up and fix the reason (instead of rebooting many times until i make it to the WB and then still don't know which script bombed)

See below for my log (sorry it's a real log, so hard to read, download and display in Multiviewer, i guess)


X: [07:30:01] Script|Process|Action|Destination|Status|Install date|Web date

S: [07:30:01] BootLog|begin|starting|BootLog|||

P: [07:30:01] BootLog|prepare|creating|boot.log|||

P: [07:30:04] BootLog|prepare|parsing|NetInterface|connected||

C: [07:30:04] BootLog|connect|parsing|Fritz Box|time server available||

C: [07:32:21] BootLog|connect|updating|Fritz Box|time and date||

F: [07:32:21] BootLog|end|stopping|BootLog|||

S: [07:32:21] Cleaner|begin|starting|Cleaner|||

C: [07:32:21] Cleaner|clean|erasing|Console logs|removing outdated logs||

C: [07:32:21] Cleaner|check|parsing|Hollywood|no temp files||

F: [07:32:21] Cleaner|end|stopping|Cleaner|||

S: [07:32:21] Updater|begin|starting|Updater|||

P: [07:32:23] Updater|prepare|initializing|CACERT|starting loop||

C: [07:32:23] Updater|connect|parsing|CACERT|site available||

C: [07:32:23] Updater|check|parsing|CACERT|no new additions|20211026|20211026

C: [07:32:23] Updater|clean|finishing|CACERT|stopping loop||

P: [07:32:26] Updater|prepare|initializing|HOSTS|starting loop||

C: [07:32:26] Updater|connect|parsing|HOSTS|site available||

C: [07:32:26] Updater|check|parsing|HOSTS|no new additions|20220103|20220103

C: [07:32:26] Updater|clean|finishing|HOSTS|stopping loop||

P: [07:32:28] Updater|prepare|initializing|PCIIDS|starting loop||

C: [07:32:28] Updater|connect|parsing|PCIIDS|site available||

C: [07:32:29] Updater|check|parsing|PCIIDS|no new additions|20211231|20211231

C: [07:32:29] Updater|clean|finishing|PCIIDS|stopping loop||

F: [07:32:29] Updater|end|stopping|Updater|||

S: [07:32:29] Fronius|begin|starting|Fronius|||

S: [07:32:29] Dimplex|begin|starting|Dimplex|||

S: [07:32:30] DarkSky|begin|starting|DarkSky|||

C: [07:32:31] Fronius|connect|parsing|Fronius|data log available||

P: [07:32:31] Fronius|prepare|registering|Notifications|||

P: [07:32:31] Fronius|prepare|initializing|Fronius|starting loop||

C: [07:32:31] Dimplex|connect|parsing|Dimplex|heating available||

P: [07:32:31] Dimplex|prepare|registering|Notifications|||

P: [07:32:31] Dimplex|prepare|initializing|Dimplex|starting loop||

C: [07:32:32] DarkSky|connect|parsing|DarkSky|site available||

P: [07:32:32] DarkSky|prepare|registering|Notifications|||

P: [07:32:32] DarkSky|prepare|initializing|DarkSky|starting loop||

S: [07:32:34] Backup|begin|starting|BackUp|||

P: [07:32:34] BackUp|prepare|parsing|Backup:|available||

C: [07:32:34] Backup|check|parsing|Backup:|valid backup found||

F: [07:32:34] Backup|end|stopping|BackUp|||

nbache

Re: X1000 occassional hanging

Posted on: 2022/1/4 23:00 #29

Just can't stay away

@Raziel

Ah, I misunderstood then. I thought it was something you ran from Network-Startup to check whether the network was up before continuing.

Best regards,

Niels

Anonymous

Re: X1000 occassional hanging

#30

@nbache

Quote:

I thought it was something you ran from Network-Startup to check whether the network was up before continuing.

Yes, that was my first try to fix the behaviour, but it wasn't working.
Actually all scripts that access the web need their own check for their own specific website to really rule out any possible hang.

Since it's easy enough to place it on top of every script it's worth it and working (for me at least)

rjd324

Re: X1000 occassional hanging

Posted on: 2022/1/22 11:51 #31

Quite a regular

This still happens from time to time and, as we know, it is easily solved by just doing a restart.

All I do in my startup-script is echo things to a file on the harddrive IFF that file does not exist. But, the last few times this has happened in the past month and I restarted the file was new, which means it was not created before, which means this is happening before the startup-script.

Anonymous

Re: X1000 occassional hanging

#32

@rjd324

Then it's pretty sure a machine exception coming from the gfx board

rjd324

Re: X1000 occassional hanging

Posted on: 2022/3/30 23:21 #33

Quite a regular

Just to add an update to this ongoing thread.

I have not been able to reproduce this issue since I swapped out my mechanical SATA drive in place of an SSD Drive.

Ever since I started using the SSD Drive with a fresh installation of the OS I simply never get any hanging.

For now the case is closed and the solution was to install a fresh OS on an SSD drive.

I will re-open this thread only if I can reproduce the issue.

Register To Post	« 1 (2)
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )