Om foutopsporing uit te voeren, moet u ondersteuning voor het TCP IP-netwerkprotocol inschakelen

laat een reactie achter 6,950

Ik kwam een ander probleem tegen in 1s 8.2. Toen ik met de configurator werkte op een win 2003 std x64-terminalserver, wilde de debugger niet starten. rapporteerde de fout: " Om foutopsporing uit te voeren, moet u ondersteuning voor het TCP/IP-netwerkprotocol inschakelen".
Alleen al de manier waarop deze fout klinkt, bracht mij in de war; ik moet het hoofdprotocol in het TCP IP-netwerk wijzigen, hoe kan dit niet worden ingeschakeld?!
Kortom, ik was de hele dag aan het surfen op de forums, sommigen adviseerden om de firewall uit te schakelen, sommigen om de poorten te openen, dit alles werd 100 keer gedaan en opnieuw gedaan, sommigen maakten zich schuldig aan antivirus, maar de staat van mijn netwerk staat mij dat niet toe doe zonder antivirus op de 1c-server, trouwens, ik heb Kaspersky Interprice 6.0 voor serverwijnen.
Nou, verdorie, ik heb het ook uitgeschakeld, ik dacht erover om het helemaal te verwijderen, maar toen kwam ik deze pagina tegen " http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=538213"

Uittreksel:
"Om te zoeken naar foutopsporingsitems is het standaard poortbereik 1560 - 1591.
Als deze poorten ergens door worden bezet of, waarschijnlijker, worden geblokkeerd door een firewall of firewall, dan wordt het genoemde bericht weergegeven.
Er zijn twee manieren.
Ten eerste kunt u dit bereik aan poorten vrijmaken of toestaan dat ze in uw firewall of firewall worden gebruikt.
Ten tweede kunt u het aantal poorten uitbreiden dat door 1C:Enterprise wordt gebruikt voor foutopsporing. In 1C:Enterprise versie 8.1.11 kunnen de poorten die worden gebruikt voor foutopsporing worden geconfigureerd met behulp van het bestand debugcfg.xml. Dit bestand moet, zoals gebruikelijk, in de conf-directory van de bin-directory worden geplaatst.
Een voorbeeldbestand is bijgevoegd.
Deze reeks poorten zal worden gebruikt door zowel Configurator als Enterprise (en anderen, bijvoorbeeld com-connector, enz.), die de foutopsporingsmodus hebben ingeschakeld."

========================================
Wat mij hier bracht: " http://www.docme.ru/doc/18889/1s-8.2-rukovodstvo-razrabotchika"

Daar las ik op mijn beurt:
========================================
"23.1.3. Extra poortbereikinstellingen
Als alle aansluitpoorten in het standaardbereik bezet zijn, is het mogelijk om een extra poort te specificeren
bereik. Dit bereik wordt geconfigureerd in het bestand debugcfg.xml, dat zich in de map bin/conf zou moeten bevinden. Als
Als het bestand niet wordt gevonden, worden poorten uit het standaardbereik (1560:1591) gebruikt voor foutopsporing. Foutopsporingsitems ingeschakeld
server gebruikt dezelfde poorten als de serverprocessen: rmngr en rphost. Extra bereiken opgeven
Er zijn geen poorten vereist voor het debuggen van items op de server.
Voorbeeld:

Meer details over het debugcfg.xml-bestand kunt u vinden in het boek "1C:Enterprise 8. Administrator's Guide."
========================================

Dat zijn allemaal jongens schild... en een schrijver! Het hielp als geen ander, ik heb eigenlijk al heel lang met dit probleem te maken, het is gewoon niet zo erg als nu. Zoals hierboven vermeld, heb ik iedereen geprobeerd, maar deze methode is het meest effectief, ik hoop dat mijn ervaring voor iemand nuttig zal zijn.

Over het algemeen ziet het er zo uit: u kunt met geen enkele netwerkdienst verbinding maken. Hier zullen we het geval bekijken waarin zowel de client als de server van u zijn. Als een partij niet van u is (bijvoorbeeld de aanbieder), sluit dan eenvoudigweg de overeenkomstige items uit de reeks acties uit of vraag mensen aan de andere kant om dit te doen. In ons voorbeeld gaan we ervan uit dat het serveradres 192.168.0.1 en poort 110 (pop3) is.

1. Eerst moet u controleren of er communicatie op IP-niveau is met de gewenste host. Om dit te doen, moet u het volgende doen:

Als het antwoord niet komt, moet je het proberen:

> ping 127.0.0.1 Als de laatste stap niet werkt, ligt het probleem in het onjuist functioneren van de TCP/IP-stack op de machine waarop u deze opdracht uitvoert. Als het laatste commando werkt, ligt het probleem hoogstwaarschijnlijk op het link- of fysieke niveau: een netwerkkaartstoring, stuurprogramma's of kabelschade (aan de client- of serverzijde). Als het Ethernet is, controleer dan eerst of de “Link”-LED op de netwerkadapter überhaupt brandt. Als de server zich op een ander subnet bevindt, moet u met tracert (onder Win) of traceroute (onder Linux) controleren waar pakketten verloren gaan. Het probleem kan te wijten zijn aan onjuiste routering.

We hebben er dus voor gezorgd dat de ping naar het juiste adres gaat. Nu is het de moeite waard om dit op servernaam te doen. Als het antwoord niet wordt geretourneerd of als de ping meldt dat de hostnaam niet kan worden opgelost, ligt het probleem bij de naamomzetting: nslookup ligt in uw handen.

2. Als ping op naam en adres wordt doorgegeven, gingen we naar de transportlaag. Laten we proberen verbinding te maken via telnet:
telnet hostpoort, in ons geval:

Als de verbinding goed is verlopen, zien we een pop3-serveruitnodiging. Voor mail.ru ziet het er ongeveer zo uit:

<[e-mailadres beveiligd]>

Als telnet zegt dat het onmogelijk is om verbinding te maken, controleer dan of de benodigde dienst überhaupt draait en of deze luistert naar de poort op de gewenste interface. Of een proces actief is of niet, kan worden achterhaald via Taakbeheer of via ProcessExplorer onder win, of via pstree onder Linux. Je kunt controleren of de gewenste socket luistert met (win) of lsof -i -n -P of netstat -l -p A inet --numeric (Linux). Als er een proces actief is, maar de poort luistert niet, dan moet je onmiddellijk kijken of een ander proces naar deze poort luistert. Als het proces vervolgens niet actief is, moet u proberen het te starten. Als dit niet werkt of de poort nog steeds niet luistert, moet u de applicatie afhandelen. Een foutenlogboek helpt meestal (bij win wordt in het geval van systeemservices meestal alles naar het systeemlogboek geschreven). Als de poort luistert, kan de reden zijn dat sommige services het bereik van adressen beperken waarmee ze kunnen worden verbonden. De debug-modus is ook erg handig.
Soms kan de reden voor het onvermogen om verbinding te maken een firewall zijn op het pad tussen de server en de client. In dit geval kunt u proberen verbinding te maken met de service vanaf dezelfde machine waarop deze wordt uitgevoerd. Meestal blokkeren firewalls en de services zelf de toegang van localhost niet.

Al het bovenstaande geldt voor toepassingen die TCP gebruiken. Indien UDP (DNS) wordt gebruikt, hoeft u alleen maar met een speciale client (nslookup, dig) te werken. Bovendien kunt u met sommige programma's zoals X-Spider handmatig gegenereerde gegevens via UDP verzenden.

3. Als we verbinding kunnen maken, proberen we een typische sessie voor dit protocol uit te voeren. Dit werkt als de gegevens in tekstvorm worden verzonden. Normaal gesproken werken de meeste gangbare protocollen (http, pop3, smtp) via gewone tekstverzending. Als dit niet het geval is, zijn er, afgezien van het gebruik van een specifieke client die de verzonden informatie gedetailleerd weergeeft voor een bepaald protocol, geen andere opties (bijvoorbeeld nslookup voor DNS). Als u telnet gebruikt, kunt u rechtstreeks met de dienst op de server werken. In ons geval zal het zoiets zijn als:

+OK mPOP POP3 v1.102+rb2-server gereed<[e-mailadres beveiligd]>

+OK Wachtwoord vereist voor gebruiker vasya_pupkin

+Oké [e-mailadres beveiligd] maildrop heeft 14 berichten (50271 octetten)

+OK 14 50271

+OK POP3-server bij mail.ru afmelden

Voor HTTP ziet het er als volgt uit:

De server geeft de startpagina weer.

Als u dit punt heeft bereikt en een normale sessie met de server via Telnet heeft gehad, ligt het probleem hoogstwaarschijnlijk bij de client.
Als de server ergens over klaagt, moet u in de richting van deze fout rondneuzen, de logbestanden bekijken, foutopsporing op de server gebruiken, enz.

Over het algemeen moet worden opgemerkt dat het erg handig is om de basiscommando's van de meest gebruikte protocollen (ftp, http, smtp, pop3) te kennen. In het geval van ftp kunt u verbinding maken met de server en de authenticatie doorstaan, maar kunt u de lijst met mappen en bestanden niet bekijken en het bestand niet ontvangen, althans niet zonder ernstige vervorming.

Ik herhaal ook nogmaals dat de debugging-modus die op de server is ingeschakeld een onmisbaar hulpmiddel is. In Kerio-producten is het bijvoorbeeld mogelijk om foutopsporing in te schakelen voor verschillende categorieën gebeurtenissen (naamresolutie, verbinding tot stand brengen, werken met mailboxen, enz.). In Unix-achtige daemons zijn de uitvoerpaden voor bewerkingslogboeken en het detailniveau meestal geconfigureerd. Het lezen van de Syslog-documentatie is ook erg nuttig.

Dr Cuddy: We hebben een diagnose nodig. Vrouw, 26 jaar, gasexplosie onder het gebouw, zij werd na 6 uur uit het puin gehaald. Twee operaties vanwege talrijke breuken en brandwonden...
Dr. Huis: Ik denk dat de gebroken botten het gevolg zijn van het instorten van een gebouw op haar hoofd.
Dr. Huis: Stel je voor dat het dak van de opslagruimte op je favoriete scrubber instort. En het begint oververhit te raken.
Schoner: Waarom zou ik van een vloerschrobmachine houden? Oké... Misschien heeft de impact iets beschadigd in de elektrische bedrading. Of er stroomde iets naar binnen en verpestte het...
Dr. Huis:HM interessant. Penetratie van infectie door snijwonden. De bacteriën zouden reageren op antibiotica. De hitte is te intens voor een virus. Mogelijk parasieten of schimmels.
Schoner:Of lupus.
Huis draait zich verbaasd om.
Schoner: Mijn grootmoeder heeft lupus.
Dr. Huis:(verbaasd) Oké, auto-immuun. Ik zal controleren op lupus. Hoewel een infectie waarschijnlijker is. Het zou leuk zijn om ook haar kaart te hebben. Laten we naar het ergste deel van de baan gaan. Om te communiceren met de familie van de vloerschrobmachine.

Dr. Huis: Op de kaart staat dat ze ziek was voordat het gebouw instortte.
De echtgenoot van de patiënt: Ik denk dat het een gewone verkoudheid is. Denk je dat dit verband houdt?
Dr. Huis: Haar ziekte met haar ziekte? Soms gebeurt het.
De moeder van de patiënt: Staat er in het dagboek dat mijn dochter deze pillen slikt?
Dr. Huis: Nee, maar vanuit medisch oogpunt...
Dr Cuddy: Heb je de pillen in haar huis gevonden?
Dr. Huis: Blijkbaar heeft ze ze in haar tas verstopt. Ik dacht dat het onfatsoenlijk zou zijn om onder de 1000 ton puin te zoeken.
Chirurg: Ze bloedt overal, tenzij de abortus met een jachtgeweer is gebeurd.

Dit artikel toont een voorbeeld van algemene principes voor het analyseren van technologische problemen die zich kunnen voordoen bij het werken met 1C:Enterprise 8.1.

Iedereen geeft graag advies, maar als het erop aankomt heeft iedereen ineens belangrijkere dingen te doen :))). Het zou waarschijnlijk eerlijk zijn om onmiddellijk te waarschuwen dat dit materiaal meer door mij is geschreven als informatie om over na te denken, en niet als een theorie voor het oplossen van persoonlijke problemen en onaangename situaties op het werk. Niettemin denk ik dat de hier gegeven voorbeelden uit mijn praktijk nuttig kunnen zijn bij het analyseren van soortgelijke problemen.

Als voorbeeld zal het volgende worden besproken:

Voorbeeld 1. Een gebruiker klaagde over de onmogelijkheid om 1C: Boekhouding te starten.

Bericht tekst:

"Fout bij het verbinden met server 1c: Enterprise 8.1:
server_addr=App1С:1540=Fout bij netwerktoegang tot server
(Windows-sockets - 10061(0x0000274D)
Er kon geen verbinding worden gemaakt omdat de doelmachine dit actief weigerde) line =567

Voorbeeld 2. De toegang tot de informatiebasis is ‘verloren’.

Bericht tekst:

Fout bij het uitvoeren van een bewerking met de infobase

Microsoft OLE DB-provider voor SQL Server: inloggen mislukt voor gebruiker 'user1c'

H RESULTAAT=80040E4D, SQLSrvr: foutstatus=1, ernst=E, native=18456, regel=1

Voorbeeld 3. Vreemde "onbekende" fout.

Tekst van het bericht: “Er is een onbekende fout opgetreden op de 1C Enterprise-server (80010108)”

1. Bepaling van de tekst (manifestatie) van de fout en lokalisatie van de bron van het optreden

Noteer de fout (tekst en/of andere informatie die nuttig kan zijn voor de analyse van het probleem). Het is beter om het probleem vast te leggen met behulp van een technologielogboek. Conclusie: als u het technologische logboek niet voor andere taken gebruikt, configureer het dan om voortdurend “uitzonderings”-gebeurtenissen (EXCP) te verzamelen en dumps te genereren in geval van een platformcrash.
Registreer het tijdstip waarop de fout is opgetreden. Dit zal verder helpen bij het lokaliseren van de locatie van de studie van verschillende logboeken.
LEES de tekst van het bericht, probeer onmiddellijk de oorzaak van het probleem te begrijpen uit de inhoud van deze tekst.
Zoek in de tekst van het bericht op internet of in andere bij jou bekende bronnen een oplossing voor het oplossen van het probleem.
Degenen die nog niet eerder met problemen met platformfouten te maken hebben gehad, zullen ze niet oplossen, zoek naar degenen die dit hebben gedaan of doen.

Opmerking. voorbeeld 1. Een zoekopdracht hieronder in de sectie “Waar kan ik een kant-en-klare oplossing vinden” met behulp van de tekst “10061” op deze pagina geeft onmiddellijk een uitleg van de reden en oplossing: De service is gestopt op de applicatieserver" 1c serveragent:Onderneming 8.1". Dienovereenkomstig moet het worden gestart, bijvoorbeeld vanaf de opdrachtregel:

net start Serveragent 1C:Enterprise 8.1

Als de toepassingsserver niet start, maakt u in sommige gevallen een kopie van de map C:\Program Files\1cv81\server en verwijdert u de inhoud voordat u probeert te starten.