Na bijna 7 jaar vonden we het wel eens tijd om een nieuwe Imac aan te schaffen. Versie 10.11.6
Maar als deze aan gaat kan ik bijna niks meer doen met internet. nsurlsessionsd gaat van meet af aan staan downloaden en het duurt vrij lang voordat de gebruiker weer eens wat mag doen.

In dit gedeelte van de wereld waar ik woon is de bandbreedte niet groot en data duur, dus zit hier niet echt op te wachten.

De suggesties die ik via google kan vinden leveren geen verbetering op. En voor zover ik weet ben ik ook niet ingelogd in iCloud.

Is het mogelijk dit te blokkeren of levert dat andere problemen op.
Verder is het denk ik nodig te vermelden dat mijn terminal of automator ervaring ongeveer nul is.

https://etrecheck.com

http://ayteck.blogspot.be/2015/09/limited-bandwidth-apple-and-hell-caused.html

In Activiteitenmonitor zie je wellicht zoiets?

En ja, een Etrecheck zou nuttig zijn.

(Bewerkt door HEXDIY om 17:40, 23-10-2016)

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.nsurlstoraged.plist

Dat was onder Mavericks. Ik heb geen idee of dit hetzelfde is onder Sierra, maar ik vermoed van wel.

Het schakelt wel ALLE iCloud gedoe uit. Gebruik het dus alleen als je geen iCloud wil.

Wat agressiever/ assertiever naar ik vermoed is het PID "nsusrlsessiond" op te sporen via Activiteitenweergave vlak na opstart, en dat PID te force quitten.

Nu lees ik ook hier en daar dat iDevices ongevraagd weer (iCloud) diensten kunnen oproepen.
Zet daarom bij wijze van test ook Bluetooth af. Evenals alle sync van iDevices.

Voorzover ik weet kunnen iDevices nog steeds synchen via USB met een Mac, zonder gebruik te maken van iCloud. Hoe weet ik niet precies, maar ik vermoed dat met alle netwerkverbindingen verbroken op zowel Mac als iDevice , maar wél iTunes open, een betrouwbare lokale sync tot stand kan worden gebracht over USB.

Call me oldfashioned...

Merk ook op dat het steevast om een download loop van ± 440 MB gaat.
Bovendien vermoed ik dat Siri online verloopt, en dat wil je niet in een regio met smalband internet.

http://www.howtoisolve.com/enable-disable-siri-on-macos-sierra-macbook-imac-mini/

Hopelijk hebben we hier de duivel bij zijn staart. Succes!

(Bewerkt door HEXDIY om 2:36, 24-10-2016)

Achtergrondliteratuur:

https://www.shinobicontrols.com/blog/ios7-day-by-day-day-1-nsurlsession

Probeer eens het Terminal commando:

Hoewel ik denk dat je bij elke herstart met het commando:

Ik ben maar een toverleerling hoor, maar deze commandos voelen juist...
En daar ga je niks kapot mee blazen.

(Bewerkt door HEXDIY om 3:32, 24-10-2016)

(Bewerkt door HEXDIY om 3:49, 24-10-2016)

https://forums.developer.apple.com/thread/61400

Checked Activity Monitor and found com.apple.SpeechRecongition and coreaudio taking the most CPU time. Speech recongition consistently takes more that 20% of CPU. I tried turning off Siri, but speech recogniztion continues to burn CPU time.

Check zeker je Activiteitenweergave!

- Nutman, hoe weet jij dat 'nsurlsessiond' de boosdoener is; waar(in) lees je dat af?
- TS zit op El Capitan.
- volgens verschillende bronnen is het proces 'nsurlsessiond' verantwoordelijk voor alle download acties, dus last vast te stellen wat precies de veroorzaker is.
- Nutman, start eens op in de Safe Mode, en check of het nu ook verkeerd gaat.
- Nutman, maak een nieuwe gebruiker op de Mac aan en log uit in de normale en log in op de nieuwe gebruiker; is er dan verschil?

HEXDIY om 1:56, 24-10-2016
Die command line set vind ik ook op het net.

Goed kijken...

Is niet hetzelfde  

Flix om 9:55, 24-10-2016
Even een paar gedachtes:

- Nutman, hoe weet jij dat 'nsurlsessiond' de boosdoener is; waar(in) lees je dat af?
- TS zit op El Capitan.

Goeie vraag. Waarschijnlijk klopt het wel. Activiteitenweergave?

Alhoewel daar veel te vaak "kernel taak" verschijnt...

Maar heel de iCloud is een kluwen waar Apple zelf niet meer aan uit geraakt. Daarom zijn ze nu bezig de verschillende authenticatie servers (iCloud/apple developer/Appstore/iTunes store...) naar één centrale om te zetten.

- volgens verschillende bronnen is het proces 'nsurlsessiond' verantwoordelijk voor alle download acties, dus last vast te stellen wat precies de veroorzaker is.

Dan zijn die bronnen zeker verkeerd. Het is een Apple only session id. Niks buiten de iCloud maakt er gebruik van. De browser niet, ftp niet...

Dus de vraag is: "Wat zijn die bronnen?"

- Nutman, start eens op in de Safe Mode, en check of het nu ook verkeerd gaat.

Nutteloos. In safe mode worden geen kernel extensies geladen en werkt nsurlsessionid niet omdat de kernel extensie die verantwoordelijk is voor encryptie en security niet werkt. Wat safe mode meestal wel verhelpt, is een vastzittende cache. De Mac zal dus sneller zijn, maar het komt terug eens je in normale mode opstart.

Ik vermoed dat het probleem van TS te maken heeft met een verkeerde/meerdere identiteiten voor één of andere Apple account. Zelf had ik er problemen mee onder Mavericks omdat ik twee developer accounts heb. En dat gooide de keys ervoor in de war. Wat later heeft Apple dat gefixt in een update. Maar sindsdien heb ik de iCloud gesloopt. Er is maar één vervelend side-effect: iTunes vraagt bij 't opstarten telkens 2 keer naar mijn iTunes account gegevens. Ik heb geen iTunes account, ik wil ook geen iTunes account. De appstore werkt wél correct. Go figure.

Maar ik zie dat regelmatig bij kopers van een tweedehands Mac. Zelfs een nieuw systeem zetten helpt niet altijd, want sommige keys zijn gekoppeld aan serienummer en zitten in de EFI partitie of zelfs in de SMC.

De details ken ik ook niet, want Apple geeft daar geen info over. Wat ik ervan weet, is door problemen te fixen na repair, als een Mac met een blanco serienummer terugkomt. Of als de SMC vervangen is, wat altijd met een recup onderdeel gebeurt. Je kan de SMC processor wel los kopen, maar om die te programmeren, is een originele onbeschadigde SMC-firmware nodig. En die heb ik niet altijd. Alles wat we daarvan weten, is reverse-engineered.

Maar het systeem loopt ook mank bij sommigen met een nieuwe Mac en een 2dehands iphone...

- Nutman, maak een nieuwe gebruiker op de Mac aan en log uit in de normale en log in op de nieuwe gebruiker; is er dan verschil?

Wedden dat een nieuwe gebruiker het niet heeft?  

Overigens is dat wel een goede test, maar niet echt in dit geval.

cyrano om 21:59, 24-10-2016

Citaat

HEXDIY om 1:56, 24-10-2016
Die command line set vind ik ook op het net.

Goed kijken...

Is niet hetzelfde  

Ach ja, dan bedoel je zeker die 2 -w flags?

cyrano om 22:20, 24-10-2016
Dan zijn die bronnen zeker verkeerd. Het is een Apple only session id. Niks buiten de iCloud maakt er gebruik van. De browser niet, ftp niet...
Dus de vraag is: "Wat zijn die bronnen?"

Het is een API, en de 'd' achter 'nsurlsession' staat volgens bronnen (mezelf, haha) voor 'daemon'. Jij noemt het een ID?

Geeft een aardige samenvatting:
Whether an app retrieves application data from a server, updates your social media status or downloads remote files to disk, it’s the HTTP network requests living at the heart of mobile applications that make the magic happen. To help you with the numerous requirements for network requests, Apple provides NSURLSession, which is a complete suite of networking API methods for uploading and downloading content via HTTP.

Kweenie hoor...

Even terug naar de OP dus. Nutman beweert dat ie niet is aangelogd op iCloud.
Waar komt dan dat excessief dataverbruik dan vandaan?

iDevices misschien?

@ Nutman: zet misschien bestandsdeling eens even af op je Mac, bij wijze van test. Evenals Bluetooth.
En wat draait er allemaal mee in je netwerk?

Sorry voor de late reactie, altijd erg druk met werk begin in de week.
Ik zal bij deze proberen de meeste vragen te beantwoorden die tot zo ver zijn gesteld.

Te beginnen met de situatie nog eens te omschrijven waarom ik nsurlsessionsd verdenk.
Op aanraden van Macmiep heb ik Little Snitch geïnstalleerd. De network monitor laat zien dat iedere keer dat ik opnieuw een netwerk verbinding maak, nsurlsessionsd ongeveer een half uur gaat staan downloaden met een snelheid van ongeveer 56.2 kB/s.
Die tijd kan ik dus geen internet gebruiken of mailen.

Er staat niks in de Photo library.

Als ik in Systeemvoorkeuren naar iCloud ga dan vraagt ie of ik eerst even wil inloggen.
Ik heb iCloud ook nooit gebruikt en wil dat ook graag zo houden.

Heb ook nog geen upgrade naar Sierra gedaan, en als ik jullie opmerkingen zo lees dan kan ik dat ook maar beter niet doen voorlopig.

Ik heb ook slechts één identiteit voor zover ik weet voor één Apple account.

Op het netwerk zit één oude iMac, die nieuwe die de problemen geeft, een oudere MacBook, een Epson ET printer en heel soms een antieke iPod. Bijna altijd shakelen we de AirPort uit als we het apparaat niet gebruiken.

Geen smartphones of tablets aanwezig.
Alleen de MacBook vraagt wel eens om een verbinding te willen maken met iCloud maar dat weigeren we altijd.

En HEXDIY ik zal je zeker niet oldfashioned gaan noemen, vooral niet omdat je hier met een fossiel te maken hebt.

En dan ook nog de etrecheck:

EtreCheck version: 3.0.6 (315)
Report generated 2016-10-25 00:17:11
Download EtreCheck from https://etrecheck.com
Runtime 2:53
Performance: Excellent

Click the [Support] links for help with non-Apple products.
Click the [Details] links for more information about that line.

Problem: No problem - just checking
Description:
nsurlsessiond data transfer

Hardware Information: ⓘ
   21.5" iMac (Late 2015)
   [Technical Specifications] - [User Guide] - [Warranty & Service]
   iMac - model: iMac16,1
   1 1.6 GHz Intel Core i5 CPU: 2-core
   8 GB RAM Not upgradeable
       BANK 0/DIMM0
           4 GB DDR3 1867 MHz ok
       BANK 1/DIMM0
           4 GB DDR3 1867 MHz ok
   Bluetooth: Good - Handoff/Airdrop2 supported
   Wireless:  en1: 802.11 a/b/g/n/ac

Video Information: ⓘ
   Intel HD Graphics 6000
       iMac 1920 x 1080

System Software: ⓘ
   OS X El Capitan 10.11.6 (15G31) - Time since boot: about 2 days

Disk Information: ⓘ
   APPLE HDD HTS541010A9E662 disk0 : (1 TB) (Rotational)
       EFI (disk0s1) <not mounted> : 210 MB
       Recovery HD (disk0s3) <not mounted>  [Recovery]: 650 MB
       Macintosh HD (disk1) /  [Startup]: 998.98 GB (973.75 GB free)
           Core Storage: disk0s2 999.35 GB Online

USB Information: &#9432;
   Broadcom Corp. Bluetooth USB Host Controller
   Apple Inc. FaceTime HD Camera (Built-in)

Thunderbolt Information: &#9432;
   Apple Inc. thunderbolt_bus

Gatekeeper: &#9432;
   Mac App Store and identified developers

Kernel Extensions: &#9432;
       /Library/Extensions
   [loaded]    at.obdev.nke.LittleSnitch (3.7 - SDK 10.11 - 2016-10-23) [Support]

System Launch Agents: &#9432;
   [not loaded]    6 Apple tasks
   [loaded]    157 Apple tasks
   [running]    75 Apple tasks

System Launch Daemons: &#9432;
   [failed]    com.apple.softwareupdate_download_service.plist (2016-03-24)
   [not loaded]    47 Apple tasks
   [loaded]    153 Apple tasks
   [running]    89 Apple tasks

Launch Agents: &#9432;
   [running]    at.obdev.LittleSnitchUIAgent.plist (2016-10-23) [Support]

Launch Daemons: &#9432;
   [running]    at.obdev.littlesnitchd.plist (2016-10-23) [Support]

User Login Items: &#9432;
   Micro Snitch Open At Login Helper    SMLoginItem  (/Applications/Micro Snitch.app/Contents/Library/LoginItems/Micro Snitch Open At Login Helper.app)

Internet Plug-ins: &#9432;
   Default Browser: 601 - SDK 10.11 (2016-10-22)
   QuickTime Plugin: 7.7.3 (2016-10-22)

3rd Party Preference Panes: &#9432;
   None

Time Machine: &#9432;
   Time Machine not configured!

Top Processes by CPU: &#9432;
        9%    WindowServer
        8%    Little Snitch Network Monitor
        5%    kernel_task
        2%    fontd
        1%    ocspd

Top Processes by Memory: &#9432;
   882 MB    kernel_task
   254 MB    Little Snitch Configuration
   90 MB    mds_stores
   90 MB    WindowServer
   82 MB    com.apple.WebKit.WebContent(2)

Virtual Memory Information: &#9432;
   3.95 GB    Free RAM
   4.05 GB    Used RAM (1.61 GB Cached)
   0 B    Swap Used

Diagnostics Information: &#9432;
   Oct 25, 2016, 12:10:48 AM    ~/Library/Logs/DiagnosticReports/EtreCheck_2016-10-25-001048_[redacted].crash
       com.etresoft.EtreCheck - /Applications/EtreCheck.app/Contents/MacOS/EtreCheck
   Oct 23, 2016, 11:51:49 PM    /Library/Logs/DiagnosticReports/softwareupdate_download_service_2016-10-23-235149_[redacted].crash
       /System/Library/CoreServices/Software Update.app/Contents/Resources/softwareupdate_download_service
   Oct 23, 2016, 12:40:47 AM    Self test - passed

Overigens is er niks mis met Sierra. Je zou eerder in jouw geval kunnen zeggen: er is iets mis met El Capitan en is je probleem waarschijnlijk ook over als je upgrade.
Maar laten we eerst maar eens kijken of we het probleem nu al op kunnen lossen.

Flix om 23:37, 24-10-2016

Citaat

cyrano om 22:20, 24-10-2016
Dan zijn die bronnen zeker verkeerd. Het is een Apple only session id. Niks buiten de iCloud maakt er gebruik van. De browser niet, ftp niet...
Dus de vraag is: "Wat zijn die bronnen?"

Ik geloof je onmiddellijk als je zegt dat het niet klopt.
Maar een bron is de Apple Developer site: About the URL Loading System
Scheelt dat?

Het is een API, en de 'd' achter 'nsurlsession' staat volgens bronnen (mezelf, haha) voor 'daemon'. Jij noemt het een ID?

Het is inderdaad een daemon. Een servertje die wacht op commando's van andere delen van 't systeem.

NSURLSession is echter ook een API, een Application Programming Interface én een object. Een object is een boodschap die van het ene deel van het systeem naar het andere reist.

NSURLSessiond is het kruispunt waar die berichten van binnen de Mac aankomen en stuurt ze door naar 't internet. Het zorgt er ook voor dat de antwoorden van 't net teruggestuurd worden naar 't juiste deel van 't systeem.

Al die namen lijken sterk op mekaar. Ze horen bij mekaar, maar hebben allemaal een precies afgebakende taak.

Ik vergis me er ook wel eens mee, vooral als het MacFreak forum weer eens nukken heeft, zoals vanavond. Het is al niet makkelijk, doordat sommige dingen niet in een nieuwe tab willen openen, vanavond zijn er weer diverse errors. Gateway onbereikbaar, 504, 404...

En ik had inderdaad ID gelezen. Dat is een ander onderdeel dat voor de aanmelding zorgt.

Ik geef het echter even op...

Ook Apple fora zijn niet meer bereikbaar. Weer een DDOS attack aan de gang?

Hoe rustig toch, Snow Leopard... Mét Ghostery, mét Little Snitch...

(Bewerkt door HEXDIY om 1:02, 27-10-2016)

Lezen hier gaat zonder probleem. Posten is nog altijd wachten. Eén keer snel, dan weer minuten...