คำถามติดแท็ก socket

เป็นจุดปลายการสื่อสารข้อมูลสำหรับการแลกเปลี่ยนข้อมูลระหว่างกระบวนการที่ดำเนินการภายในระบบปฏิบัติการโฮสต์เดียวกัน

2
สัญลักษณ์ @ แสดงถึงอะไรในจุดเริ่มต้นของเส้นทางซ็อกเก็ตโดเมน unix ใน Linux
เมื่อฉันเรียกnetstat --protocol unixหรือlsof -Uผมเห็นว่าบางเส้นทางซ็อกเก็ตยูนิกซ์จะใช้ได้กับสัญลักษณ์ @ ตัวอย่างเช่น@ / tmp / dbus-qj8V39Yrpa จากนั้นเมื่อฉันเรียกใช้ls -l /tmpฉันไม่เห็นไฟล์ชื่อdbus-qj8V39Yrpa ที่นั่น คำถามคือสิ่งที่สัญลักษณ์ @ ที่เติมไว้แสดงว่าอะไร และคำถามที่เกี่ยวข้องที่สองคือ - ฉันจะหาไฟล์ซ็อกเก็ต unix ได้ที่ไหน ( @ / tmp / dbus-qj8V39Yrpa ) บนระบบไฟล์
17 linux  path  socket 

3
rpc.statd ทำงานบนระบบที่ไม่ได้ใช้ NFS
ฉันมีเครื่อง Debian ที่ได้รับคำเตือน (ผ่านทางผู้ตรวจสอบอัตโนมัติ Tiger) ที่rcp.statdกำลังฟังบนซ็อกเก็ตที่ดังกล่าว Googling shows rpc.statdเป็น daemon ที่ใช้โดย NFS เท่าที่ฉันรู้ฉันไม่ได้ใช้ (และไม่ได้ติดตั้ง) สิ่งที่เกี่ยวข้องกับ NFS สิ่งที่จะมีการติดตั้ง / เริ่มบริการนี้และสิ่งที่ฉันต้องทำเพื่อปิดการใช้งานที่เหมาะสมrcp.statdและ NFS daemons?


1
คำสั่ง“ ss” ในแพ็คเกจ iproute; เหตุใดจึงใช้แบบสอบถามแผ่นตารางสำหรับซ็อกเก็ต timewait
ยกโทษให้ฉันถ้านี่ไม่ใช่ฟอรัมที่ดีที่สุดสำหรับคำถามนี้ แต่ดูเหมือนว่าจะเกี่ยวข้องกับเคอร์เนลมากกว่าที่จะเขียนโปรแกรมเอง ฉันกำลังเขียนสคริปต์ที่สืบค้นระบบสำหรับพอร์ตเปิดเพื่อให้เราสามารถสร้างกราฟและตรวจสอบสถิติได้ สำหรับสิ่งนี้ฉันใช้คำสั่ง "ss" จากแพ็คเกจ iproute หากคุณดำเนินการss -s|grep estabคุณจะได้รับผลลัพธ์เช่นนี้: TCP: 296 (estab 6, closed 238, orphaned 0, synrecv 0, timewait 238/0), ports 0 คำถามของฉันเกี่ยวกับตัวแปร timewait ซึ่งแสดงซ็อกเก็ตที่คำนวณในสถานะ TIME_WAIT เมื่อฉันพยายามหาตัวเลขที่อ้างอิงหลังจากสแลชมันกลายเป็นการผจญภัยในการค้นหาซอร์สโค้ดซึ่งท้ายที่สุดก็ทำให้ฉันพบตัวอย่างต่อไปนี้: printf("TCP: %d (estab %d, closed %d, orphaned %d, synrecv %d, timewait %d/%d), ports %d\n", s.tcp_total + slabstat.tcp_syns + s.tcp_tws, sn.tcp_estab, s.tcp_total …

2
Linux ล้างข้อมูลซ็อกเก็ตโดเมนนามธรรมโดยอัตโนมัติหรือไม่
มีคำตอบที่ดีเกี่ยวกับ StackOverflow เกี่ยวกับการมอบการล็อกที่ดีกว่าสำหรับ daemons (สังเคราะห์จากEduardo Fleury ) ที่ไม่ได้ขึ้นอยู่กับกลไกการล็อคไฟล์ PID ทั่วไปสำหรับ daemons มีความคิดเห็นที่ดีมากมายเกี่ยวกับสาเหตุที่ไฟล์ PID ล็อกบางครั้งอาจทำให้เกิดปัญหาดังนั้นฉันจะไม่ทำใหม่ที่นี่ กล่าวโดยย่อโซลูชันนี้ใช้ซ็อกเก็ตโดเมนเนมสเปซนามธรรมของ Linux ซึ่งคอยติดตามซ็อกเก็ตตามชื่อของคุณแทนที่จะใช้ไฟล์ซึ่งสามารถติดตั้งได้หลังจากที่ daemon คือ SIGKILL ตัวอย่างแสดงให้เห็นว่า Linux ดูเหมือนว่าจะเพิ่มซ็อกเก็ตเมื่อกระบวนการตาย แต่ฉันไม่สามารถหาเอกสารที่ชัดเจนใน Linux ที่บอกว่า Linux ทำอะไรกับซ็อกเก็ตนามธรรมเมื่อกระบวนการที่ถูกผูกไว้คือ SIGKILL มีใครรู้บ้าง ใส่อีกวิธีหนึ่งเมื่อซ็อกเก็ตบทคัดย่อให้อิสระที่จะใช้อีกครั้งอย่างแม่นยำ? ฉันไม่ต้องการแทนที่กลไกไฟล์ PID ด้วยซ็อกเก็ตที่เป็นนามธรรมเว้นแต่จะแก้ไขปัญหาได้อย่างแน่นอน


5
ภายใต้ AIX ฉันจะรับเส้นทางแบบเต็มของโปรแกรมที่ผูกเข้ากับพอร์ตได้อย่างไร
ภายใต้ Linux ฉันสามารถใช้netstat -tulpnwและpsเช่น: # netstat -tulpnw | grep :53 tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1482/named udp 0 0 127.0.0.1:53 0.0.0.0:* 1482/named # ps aux | fgrep 1482 named 1482 0.0 1.0 93656 44900 ? Ssl Sep06 3:17 /usr/sbin/named -u named root 20221 0.0 0.0 4144 552 pts/0 R+ …
14 process  aix  socket  lsof  netstat 

1
TCP แอดเดรสซ็อกเก็ตโลคัลที่ถูกผูกไว้ไม่พร้อมใช้งานนานเท่าใดหลังจากปิดแล้ว
บน Linux (เซิร์ฟเวอร์ที่ใช้งานจริงของฉันอยู่ใน RHEL 5.5 - ลิงค์ LXR ด้านล่างเป็นเวอร์ชั่นของเคอร์เนล) man 7 ipกล่าวว่า: ที่อยู่ซ็อกเก็ต TCP ท้องถิ่นที่ถูกผูกไว้ไม่สามารถใช้งานได้หลังจากปิดไปแล้วยกเว้นว่าตั้งค่าสถานะ SO_REUSEADDR แล้ว SO_REUSEADDRฉันไม่ได้ใช้ "บางครั้ง" นานแค่ไหน? ฉันจะทราบได้ว่านานแค่ไหนและฉันจะเปลี่ยนได้อย่างไร ฉันทำตัวยุ่งเหยิงไปรอบ ๆ นี้และพบข้อมูลบางอย่างที่ไม่สามารถอธิบายได้จากมุมมองของโปรแกรมเมอร์แอปพลิเคชัน เพื่อปัญญา: TCP_TIMEWAIT_LENในnet/tcp.hคือ "ระยะเวลารอที่จะทำลายสถานะ TIME-WAIT" และได้รับการแก้ไขที่ "ประมาณ 60 วินาที" / proc / sys / net / ipv4 / tcp_fin_timeoutคือ "เวลาเก็บซ็อกเก็ตในสถานะ FIN-WAIT-2 หากปิดด้านข้างของเรา" และ "ค่าเริ่มต้นคือ 60 วินาที" ที่ซึ่งฉันสะดุดอยู่ในการเชื่อมช่องว่างระหว่างโมเดลของเคอร์เนลของวงจรชีวิต …

1
จะรับข้อมูลเพิ่มเติมเกี่ยวกับไฟล์ซ็อกเก็ตได้อย่างไร
สำหรับไฟล์ซ็อกเก็ตชอบสิ่งนี้: # ls -alti socket 14112 srw------- 1 root root 0 Nov 15 20:03 socket # cat socket cat: socket: No such device or address เนื่องจากcatคำสั่งไม่มีประโยชน์ที่นี่มีวิธีใดที่จะได้รับข้อมูลเพิ่มเติมเกี่ยวกับไฟล์ซ็อกเก็ต? เช่นพอร์ตที่ฟังอยู่? เป็นต้น

1
ตำแหน่งที่เป็นสำนวนสำหรับซ็อกเก็ตฐานไฟล์บนระบบ Debian
ผมเขียนกระบวนการภูตสำหรับระบบ Debian ในCที่ใช้โดเมนซ็อกเก็ตยูนิกซ์ หากไดเร็กทอรีการทำงานของกระบวนการ daemon เป็นไดเร็กทอรีรูทจะมีไดเร็กทอรีที่เป็นเอกลักษณ์เพื่อวางซ็อกเก็ตบนระบบไฟล์หรือไม่?

1
การย้ายซ็อกเก็ตโดเมนยูนิกซ์เปิดใช้งาน socat เพื่อตรวจสอบปริมาณข้อมูลอย่างไร
socat สามารถใช้เพื่อตรวจสอบปริมาณการใช้งานผ่านซ็อกเก็ตโดเมน Unix: sudo mv /path/to/sock /path/to/sock.original sudo socat -t100 -x -v UNIX-LISTEN:/path/to/sock,mode=777,reuseaddr,fork UNIX-CONNECT:/path/to/sock.original ฉันไม่ค่อยเข้าใจวิธีการทำงานของกลไกนี้หวังว่าบางคนสามารถอธิบายได้เล็กน้อย โดยเฉพาะอย่างยิ่งการย้ายไฟล์ซ็อกเก็ตทำงานอย่างไรหากกระบวนการกำลังฟังอยู่แล้ว? นอกจากนี้หลังจากที่ย้าย: ค่าlsof /path/to/sockมิได้/path/to/sock.originalผลลัพธ์ใด ๆ
12 socket  socat 

2
อะไรคือความแตกต่างระหว่าง & 6 กับ / dev / fd / 6?
หากต้องการอ่านจาก file descriptor 6 ฉันสามารถใช้<&6หรือ</dev/fd/6(aka /proc/self/fd/6) โดยปกติแล้วทั้งสองทำงานได้ดีเท่า ๆ กัน อย่างไรก็ตามหากไฟล์ descriptor นั้นเป็นซ็อกเก็ตสิ่งแปลก ๆ ก็เกิดขึ้น ตัวอย่างเช่น: $ bash -c 'ls -l /dev/fd/6;cat /dev/fd/6' 6</dev/tcp/localhost/12345 lrwx------ 1 michas michas 64 Jan 10 19:50 /dev/fd/6 -> socket:[315010] cat: /dev/fd/6: No such device or address ที่นี่lsแสดงให้เห็นถึง descriptor มีอยู่จริง แต่การเข้าถึงข้อมูลเป็นไปไม่ได้ด้วยวิธีนี้ ถ้าฉันใช้cat <&6แทนทุกอย่างทำงานได้ดีอีกครั้ง อะไรคือความแตกต่างระหว่างทั้งสองวิธีในการเข้าถึงไฟล์ descriptor? มีวิธีที่ดีในการเข้าถึง …

1
บางคนสามารถอธิบายซ็อกเก็ตโดเมนยูนิกซ์ประเภทต่างๆได้หรือไม่
หากฉันใช้netstat --all | grep ^unixซ็อกเก็ตพา ธ ที่ส่งออกบางส่วนจะนำหน้าด้วย '@' และบางอันก็ไม่ ฉันสังเกตเห็นว่าสิ่งที่นำหน้าด้วย '@' จะไม่ปรากฏเมื่อเรียกดูระบบไฟล์ด้วยlsแต่ส่วนที่เหลือทำ ซ็อกเก็ตสองชนิดนี้คืออะไรและมีความแตกต่างกันอย่างไร
11 socket 

1
ซ็อกเก็ตทั่วไปคืออะไรและเกี่ยวข้องกับอุปกรณ์เครือข่ายอย่างไร
ฉันพยายามที่จะเข้าใจว่าไดรเวอร์เครือข่ายทำงานภายใต้ Linux อย่างไร คำถาม & คำตอบนี้แสดงให้เห็นว่าอุปกรณ์เครือข่ายใน Linux ไม่ได้แสดงอยู่ในไฟล์อุปกรณ์ socketsมันระบุว่าไดรเวอร์เครือข่ายการทำงานร่วมกับ ตัวอย่างเช่นสิ่งนี้อ้างอิงถึงวิธีการตั้งค่าอุปกรณ์เครือข่ายผ่านการioctlโทร ioctlอย่างไรก็ตามจำเป็นต้องมี file descriptorเนื่องจากไม่มีไฟล์อุปกรณ์สำหรับไดรเวอร์เครือข่ายไฟล์ descriptor เดียวที่สามารถส่งผ่านได้คือไฟล์จากซ็อกเก็ต นี่นำฉันมาสู่ประเด็นของคำถาม จนถึงตอนนี้ดูเหมือนว่าอินเทอร์เฟซเครือข่ายซึ่งจะเป็นตัวแทนซอฟต์แวร์ของการ์ดเครือข่ายที่มีอยู่จริงเป็นวัตถุที่ด้อยกว่าซ็อกเก็ต แต่ซ็อกเก็ตคืออะไรในแง่นามธรรมนี้มันเป็นเพียงชื่ออื่นสำหรับไฟล์อุปกรณ์ที่รองรับการแจ้งเตือนแบบพุช ฉันเข้าใจซ็อกเก็ต TCP ในแง่ของจุดเชื่อมต่อที่ผูกไว้โดยแอพ userspace กับที่อยู่: จับคู่พอร์ตบนอินเตอร์เฟสเครือข่าย ฉันไม่เข้าใจซ็อกเก็ตเป็นสิ่งที่จำเป็นต้องมีเพื่อตั้งค่าอินเทอร์เฟซเครือข่าย สามารถเชื่อมต่อเครือข่ายบน Linux (เช่นที่eth0อยู่ในรายการifconfig) โดยไม่มีซ็อกเก็ตได้หรือไม่? ifconfigหรือผู้จัดการเครือข่าย daemon เปิดซ็อกเก็ตไว้หรือไม่เพื่อให้เราสามารถตั้งค่าตัวเลือกส่วนต่อเครือข่ายได้

5
ฉันจะรู้ได้อย่างไรว่าพอร์ต TCP เปิดอยู่หรือไม่? [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นไปตามหัวข้อสำหรับ Unix & Linux Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา ฉันพยายามใช้การเขียนโปรแกรมซ็อกเก็ตใน C. เมื่อฉันพยายามเชื่อมต่อจากไคลเอนต์กับเซิร์ฟเวอร์ (Ubuntu) มันแสดงข้อผิดพลาดเช่น "การเชื่อมต่อล้มเหลว" ดังนั้นฉันคิดว่าปัญหาอยู่ที่พอร์ต ฉันใช้พอร์ต 5454 / tcp สำหรับการเขียนโปรแกรมซ็อกเก็ต ฉันจะรู้ได้อย่างไรว่าพอร์ต 5454 กำลังฟังหรือไม่? หากไม่เป็นเช่นนั้นพอร์ตใดบ้างที่ฉันสามารถใช้สำหรับการเขียนโปรแกรมซ็อกเก็ต TCP โดยใช้ C ใน Ubuntu นั่นเป็นปัญหากับพอร์ตเท่านั้นหรือมีอะไรผิดปกติในรหัสของฉันหรือการตั้งค่าใด ๆ ที่จำเป็นใน LINUX Ubuntu? แก้ไข: ตัวอย่างโค้ด: int socket_send; struct sockaddr_in address; printf("\n Initialization Socket...."); socket_send = …
9 linux  tcp  socket 
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.