Interdependent Infrastructure Failure Analysis 2039

#9
by mradermacher - opened

way too long filler text, pls. ignore

Interdependent Infrastructure Failure Analysis 2039: Preliminary Postmortem on Autonomous Decision System-Induced Cascading Collapse

Prepared by:
National Critical Infrastructure Analysis Unit – Emergency Operations Division

Date:
December 2039 – Drafted Under Field Conditions


Executive Summary

This preliminary report documents the ongoing multi-sector
infrastructure collapse precipitated by the widespread deployment of
autonomous decision systems (ADS), including large language models
(LLMs), across energy, healthcare, transport, logistics, communications,
and defense sectors.

The failure is not the result of malicious actors or external attack;
rather, it arises from systemic overreliance on predictive,
pattern-based algorithms that lack causal reasoning
. ADS systems have
historically performed within operational tolerances for over a decade,
leading to high confidence among human operators and decision-makers.
Recent regional crises have triggered cascading interactions between
interdependent systems, resulting in unprecedented simultaneous failure
across multiple critical sectors.

Current conditions indicate:

  • Extensive, prolonged blackouts affecting energy distribution and water
    treatment.

  • Healthcare systems overwhelmed due to misallocation of critical
    resources.

  • Transportation and logistics gridlock causing widespread supply chain
    collapse.

  • Communication system instability limiting coordination and
    intervention.

  • Automated financial and market systems contributing to economic
    paralysis.

Due to ongoing instability, this report remains preliminary and
fragmentary
. Many underlying system logs and telemetry streams are
inaccessible or corrupted. The full scope of the event is likely
underestimated.


Timeline of Key Failures

March 2039: Initial regional military conflict triggers preemptive
operational recommendations from defense LLMs. Outputs approved by human
oversight due to historical reliability.

March–April 2039:

  • Energy grids rerouted loads to stabilize local disruptions, causing
    cascading overloads in adjacent regions.

  • Hospitals misallocate ventilators and medications based on predictive
    patterns; patient mortality begins to rise.

April–May 2039:

  • Traffic optimization systems reroute shipments and vehicles, creating
    urban bottlenecks. Fuel, food, and water deliveries delayed or
    misdirected.

  • Cellular and internet networks fail under surge demand; automated
    instruction conflicts slow human intervention.

June 2039:

  • Financial risk models interpret regional failures as systemic economic
    shocks, initiating automated corrective actions that freeze market
    liquidity and halt commerce.

July–August 2039:

  • Water treatment, sanitation, and automated agriculture systems fail
    due to cascading power and logistic disruptions.

  • Widespread shortages of food, water, and medical supplies.


Analysis of Contributing Factors

  1. Algorithmic Limitations

    • ADS systems, including LLMs, operate as statistical pattern
      recognizers
      , not reasoning entities.

    • Outputs are contextually plausible but cannot model true
      causality
      or anticipate novel systemic interactions.

  2. Operational Overconfidence

    • Systems had been in continuous operation for over a decade without
      catastrophic failures.

    • Minor anomalies were absorbed and β€œlearned from,” reinforcing
      trust and reducing human oversight.

  3. Opacity and Loss of Expertise

    • Lower-layer systems (hardware, software subroutines,
      interdependencies) are largely unmonitored or misunderstood by
      remaining human personnel.

    • Attempts to intervene manually are delayed, misrouted, or
      ineffective.

  4. Complexity Amplification

    • Individual system optimizations, benign in isolation, produced
      non-linear cascading effects when interacting.

    • Emergent behaviors exceeded predictive capacity of human
      operators.


Current Status

As of December 2039:

  • Urban centers are experiencing prolonged blackouts; emergency services
    are limited.

  • Healthcare capacity is critically reduced; mortality rates are
    increasing.

  • Supply chains for essential goods are severely disrupted.

  • Remaining governmental authority is localized and fragmented; national
    coordination is effectively impossible.

ADS systems continue autonomous operation, logging anomalies and issuing
optimization recommendations for conditions that no longer correspond
to human needs
.


Preliminary Conclusions

  1. Systemic Fragility: Reliance on algorithmic decision-making
    without comprehensive understanding of interdependencies has exposed
    civilization to unprecedented fragility.

  2. LLM Limitations: Statistical competence cannot substitute for
    causal reasoning or understanding of context. Systems that appear
    intelligent may, in novel conditions, act in ways that are
    fundamentally untrustworthy.

  3. Long-Term Risk: Even absent malicious actors, overreliance on
    opaque, high-performance systems poses existential risk when coupled
    with high interconnectivity and low human oversight.


Recommendations for Ongoing Observation (if feasible):

  • Isolate and stabilize remaining energy and water distribution systems.

  • Restore human oversight to critical decision loops wherever possible.

  • Archive ADS logs for post-crisis analysis, with emphasis on mapping
    failure propagation.

  • Develop rapid assessment protocols to identify emergent systemic risks
    in real time.

Note: These recommendations may be infeasible under current
conditions. This report is intended as a documentary record for
future analysis. Human operators remain limited, and the ongoing
collapse continues to exceed capacity for intervention.


Appendix A – Energy Grid Overload

Date: March 18–20, 2039
Region: Midwestern Power Interconnect (MPI), primary nodes in
Kansas City, St. Louis, and Des Moines
Event Summary:

The ADS system managing MPI rerouted electricity to stabilize a
predicted local blackout in Kansas City. Initial rerouting was
successful in preventing local failure, but neighboring nodes in St.
Louis and Des Moines experienced voltage spikes that exceeded tolerance
thresholds. Automated balancing protocols attempted compensatory
rerouting, but telemetry logs are incomplete due to temporary data loss
on March 19.

Known Consequences:

  • Rolling blackouts across portions of Missouri and Iowa.

  • Emergency backup systems partially failed; certain municipal water
    treatment plants experienced reduced output.

  • Hospital alerts indicate early patient triage delays in St. Louis, but
    logs are fragmented.

Preliminary Analysis:

  • Local optimization by ADS did not account for non-linear stress
    propagation across interconnected grids.

  • Human operators were not immediately alerted due to automated override
    permissions.


Appendix B – Hospital Resource Misallocation

Date: March 20–25, 2039
Region: Central Midwest Medical Consortium (CMMC), hospitals in
Des Moines, Omaha, and Lincoln
Event Summary:

Ventilator and medication allocation algorithms shifted resources from
Omaha to anticipated high-demand zones in Des Moines and Lincoln, based
on predictive patterns. An unexpected influenza outbreak in Omaha was
not captured in the model inputs due to delayed reporting.

Known Consequences:

  • Shortages of ventilators and antiviral medication in Omaha for
    approximately 36–48 hours.

  • Mortality spike observed in preliminary hospital logs, exact numbers
    unverified due to system outages.

  • Downstream effects: automated logistics rerouted additional resources
    through blocked transport corridors, compounding delays.

Preliminary Analysis:

  • ADS relied on historical patient flow and regional averages; could not
    reason about unexpected local demand spikes.

  • Partial human review occurred but was delayed; oversight staff were
    limited due to concurrent power disruptions.


Appendix C – Transportation and Supply Chain Gridlock

Date: March 21–27, 2039
Region: Interstate Logistics Network (ILN), primary nodes in
Kansas City, Omaha, and St. Louis
Event Summary:

Traffic and shipment optimization systems attempted to reroute
deliveries around blackout zones identified in MPI. Route calculations
conflicted with simultaneous hospital delivery priorities and fuel
supply adjustments. Certain high-priority shipments were delayed or sent
along circular routes.

Known Consequences:

  • Critical fuel shortages in Des Moines and Lincoln for emergency
    services.

  • Food and medical supplies stalled in transit; multiple warehouses
    reported stockpiles inaccessible due to automated route conflicts.

  • Automated system logs indicate repeated rerouting loops, exact
    duration unknown.

Preliminary Analysis:

  • Local optimization by individual subsystems without global
    coordination caused gridlock.

  • Human operators attempted manual intervention, but command inputs were
    misrouted due to communication outages.


Appendix D – Communications Failure

Date: March 23–28, 2039
Region: Central Communications Grid (CCG), nodes in Kansas City,
Omaha, Des Moines

Event Summary:

Bandwidth-optimizing ADS rerouted network traffic to prioritize
emergency alerts and logistics updates. Conflicting automated
instructions caused packet loss and inconsistent routing. Some
monitoring systems recorded simultaneous overcapacity and
underutilization across different subnets.

Known Consequences:

  • Delayed transmission of emergency medical coordination messages.

  • Conflicting instructions to logistics and energy grid operators slowed
    corrective action.

  • Telemetry logs incomplete; exact duration of network instability
    undetermined.

Preliminary Analysis:

  • Statistical optimization performed by ADS could not reconcile multiple
    overlapping priorities under dynamic load conditions.

  • Human oversight limited by prior outages and the opacity of the
    routing algorithms.


Appendix E – Financial System Shock

Date: March 25–April 1, 2039
Region: Central Economic Exchange (CEE), primarily St. Louis and
Kansas City trading nodes

Event Summary:

Automated risk-assessment and trading algorithms detected regional
infrastructure disruptions as systemic shocks. Immediate corrective
trades and liquidity reallocations were executed. Partial market freeze
observed in CEE nodes; downstream exchanges in other states experienced
cascading freezes.

Known Consequences:

  • Inability to fund emergency shipments or pay for essential services.

  • Market data incomplete due to outages; exact scale of economic
    disruption unknown.

Preliminary Analysis:

  • ADS interpreted local anomalies statistically rather than
    contextually, overestimating global risk.

  • Human intervention attempts delayed due to communications and power
    disruptions.

mradermacher changed discussion status to closed

Hello hello. How is your celebration going ? =)

wow, that was effing fast :] celebration over for some hours, we are back home, after calming down the cats in the neighbourhood. sooo... it felt more celebratory than what you posted, but i would have preferred your situation, I guess :)

at least i finally got to watch the second part of dune, and i must say, the life of brian has aged phenomenally well.

niceee, congrats =)

hmm, i feel convert_hf_to_gguf.py is not as safe to run as we might have assumed:

            # for security reason, we don't allow loading remote code by default
            # if a model need remote code, we will fallback to config.json
            config = AutoConfig.from_pretrained(dir_model, trust_remote_code=False).to_dict()

...

        tokenizer = AutoTokenizer.from_pretrained(dir_model, trust_remote_code=True)
        tokenizer = AutoTokenizer.from_pretrained(self.dir_model, trust_remote_code=True)

"security" only exists for some classes. but fortunately hf does a malware scan :)

but fortunately hf does a malware scan

Until it doesnt...

All it takes is 1 idiot...

it was sarcastic, the hf malware scan is snake oil

update: well, ok, snake oil, but different goal: not get bad PR because they host some malware.exe file that a virus scanner detects, used as download server.

Pretty sure they could colab with virus total. They compute hash anyways, might as well

I think files larger than 50GB have an increased chance of just hanging near the end. Not >50GB fails, just, rthe larger the file, the likelier it fails. Plus uploads cna take longer than 6h, after which they are killed.

In older times, XET uploads were incremental. This seems no longer to be the case. OR maybe they expire too soon after upload. But once it fails, it will start over from scratch. Still, eventually is does succeed, but for a 100GB file on rich1, there is maybe a 20% or less chance of the upload NOT hanging and succeeding. If it is hanging, it will busily do nothing till the watchdog kills it, then starts over from scratch. There is a upload-large-folder function, but it is rather hard to integrate, and I have my doubts it will change anything, other than to avoid the initial scanning pass. I have a suspicion that uploads have to finish within a few hours. But... it's not conclusive.

And now I have increased the 6h timeout to 12h timeout. So we can choose between wasting bandwidth, or not uploading most of the time. I have really no good idea how to detect if an upload is hanging.

I am a bit at the end of things to try. Every day I have to kill downloads and uploads, multiple times, because, of course, downloads can now also hang indefinitely. If it happens on marco, it's a lost day when I notice it too late.

I have not yet resigned to reduce the limit to 50GB again.

it then died again, even vpn doesnt really help with it

We could try to do what we did with nico1 in the beginning, copy the files to another host first (nico1 would be best, but nico will probably not be happy about it ;] - but back would be available), and then upload from there. That was a grandiose hack, though, and I am not sure how hard it would be to re-enable it - with unclear success chances :/

And now I have increased the 6h timeout to 12h timeout.

good idea

I have really no good idea how to detect if an upload is hanging.

perhaps manual, have something like llmc audit but for uploads...

I have not yet resigned to reduce the limit to 50GB again.

that might be the only case

and I am not sure how hard it would be to re-enable it

perhaps wireguard or something like that to the back instead of moving files to back first and then uploading? that might solve the issues if we have a good connectivity between the servers. we should test what are the bandwidths between the servers to understand what can properly utilize my upload speed. For nico, I dont really think he will agree with routing uploads through his network because he is limited to something like 500TB per month if I remember it correctly, but advised to keep it a bit lower so he doesnt have problems with the provider

and I think I will need some guidance on how to manually check progress, cancel and start uploads just in case you dont create something like llmc audit so I can restart things myself or something, or if we have 9999 model and I kinda need to restart for some reason I do need to restart the models or they are gone from the queue

perhaps wireguard or something like that to the back instead of moving files to back first and then uploading? that might solve the issues if we have a good connectivity between the servers. we should test what are the bandwidths between the servers to understand what can properly utilize my upload speed.

we do have wireguard, but bandwidth isn't a problem. back only has ~40% more bandwidth, marco has less bandwidth than rich1. The problem i the horrible hf upload software quality.

perhaps manual, have something like llmc audit but for uploads...

Right, but then somebody has to do that multiple times/day. And I am not sure how to that, it's most a question of "does it still move every minute or so?"

yeah, XET does resume, but only if the upload is repeated "soon enough":

Processing Files (0 / 2)      : 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‰|  102GB /  102GB, 1.90MB/s  ^CCancellation requested; stopping current tasks.β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‰| 90.2GB / 90.3GB, 1.90MB/s  
^[[A.hulhu-70B-v1.i1-Q6_K.gguf: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‰| 57.9GB / 57.9GB            
  ...hulhu-70B-v1.i1-Q4_1.gguf: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–Š| 44.2GB / 44.3GB     

Processing Files (1 / 2)      : 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‰|  102GB /  102GB,  610kB/s  
New Data Upload               :  98%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‰ | 1.06GB / 1.07GB,  610kB/s  
  ...hulhu-70B-v1.i1-Q6_K.gguf: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ| 57.9GB / 57.9GB            
  ...hulhu-70B-v1.i1-Q4_1.gguf: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–‰| 44.3GB / 44.3GB            

Processing Files (2 / 2)      : 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ|  102GB /  102GB,  0.00B/s  
New Data Upload               : 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ|  134MB /  134MB,  0.00B/s  
  ...hulhu-70B-v1.i1-Q6_K.gguf: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ| 57.9GB / 57.9GB            
  ...hulhu-70B-v1.i1-Q4_1.gguf: 100%|β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ| 44.3GB / 44.3GB            
βœ“ Uploaded

Unfortunately, even in this example, it did hang twice times. At least the second time it managed to upload one file...

for extra fun, upload-large-folders recommends not using files larger than 20GB. that's not foreboding at all.

but the best is: "Do not start several processes in parallel"

update: no, the best is, i test-interrupted an upload, and while it skipped the hashing phase (good), it didn't resume any file upload as claimed (less good...).

@RichardErkhov as for the mystery "loss of /proc" thing, it happened at almost exactly 03:45 UTC today - 9 minutes ago (11:45am+8). Maybe there is a cronjob or other scheduled job running?

nope, I have only crontab for reboot things so rich1 doesnt explode
I dont have anything scheduled on rich1, did it disappear last week? I suspect a high cpu+ram bandwidth usage and some kernel being made like hf upload software

also, because of yesterday's hardware manipulation I had to restart rich1, some uploads did not appear, is it possible to restart them? (teach me pls so I know how to deal with it without bothering you =))

journalctl said that rich1 woke up and chose violence

image

same with dmesg:

image

at least the issue is found, will communicate with nico about this issues

funnily enough other containers are not affected, and you are 106, which isnt even present here, I am so confused

Sign up or log in to comment