Score:1

จะเริ่ม etcd ใน docker จาก systemd ได้อย่างไร?

ธง jp

ฉันต้องการเริ่ม etcd (โหนดเดียว) ในนักเทียบท่าจาก systemd แต่มีบางอย่างผิดพลาด - จะถูกยกเลิกประมาณ 30 วินาทีหลังจากเริ่มต้น

ดูเหมือนว่าบริการจะเริ่มในสถานะ "เปิดใช้งาน" แต่ถูกยกเลิกหลังจากนั้นประมาณ 30 วินาทีโดยไม่ถึงสถานะ "คล่องแคล่ว". อาจมีการส่งสัญญาณที่ขาดหายไประหว่าง docker container และ systemd?

อัปเดต (ดูด้านล่างของโพสต์): ถึงสถานะบริการ systemd ล้มเหลว (ผลลัพธ์: หมดเวลา) - เมื่อฉันถอด รีสตาร์ท = เมื่อล้มเหลว การเรียนการสอน.

เมื่อฉันตรวจสอบสถานะของบริการ etcd หลังจากบูต ฉันได้รับผลลัพธ์นี้:

$ sudo systemctl สถานะ etcdâ etcd.service - etcd โหลดแล้ว: โหลดแล้ว (/etc/systemd/system/etcd.service; เปิดใช้งาน; ค่าที่ตั้งไว้ล่วงหน้าของผู้ขาย: ปิดใช้งาน)
   ใช้งานอยู่: กำลังเปิดใช้งาน (รีสตาร์ทอัตโนมัติ) (ผลลัพธ์: exit-code) ตั้งแต่วันพุธที่ 2021-08-18 20:13:30 UTC; 4 วินาทีที่แล้ว
  กระบวนการ: 2971 ExecStart=/usr/bin/docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data --name etcd my-aws-account.dkr.ecr.eu- north-1.amazonaws.com/etcd:v3.5.0 /usr/local/bin/etcd --data-dir=/etcd-data --name etcd0 --advertise-client-urls http://10.0.0.11: 2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://10.0.0.11:2380 --listen-peer-urls http://0.0.0.0: 2380 --initial-cluster etcd0=http://10.0.0.11:2380 (รหัส=ออก, สถานะ=125)
 PID หลัก: 2971 (รหัส=ออก สถานะ=125)

ฉันเรียกใช้สิ่งนี้บนเครื่อง Amazon Linux 2 โดยมีสคริปต์ข้อมูลผู้ใช้ให้เรียกใช้เมื่อเปิดตัว ฉันได้รับการยืนยันว่า นักเทียบท่า.บริการ และ นักเทียบท่า_ecr_login.service ทำงานสำเร็จ

และหลังจากเปิดเครื่องได้ไม่นาน ฉันเห็นว่า etcd กำลังทำงานอยู่:

 สถานะ sudo systemctl เป็นต้น
â etcd.บริการ - etcd
   โหลดแล้ว: โหลดแล้ว (/etc/systemd/system/etcd.service; เปิดใช้งาน; การตั้งค่าล่วงหน้าของผู้ขาย: ปิดใช้งาน)
   ใช้งานอยู่: กำลังเปิดใช้งาน (เริ่มต้น) ตั้งแต่วันพุธที่ 2021-08-18 20:30:07 UTC; 1 นาที 20 วินาทีที่แล้ว
 PID หลัก: 1573 (นักเทียบท่า)
    งาน: 9
   หน่วยความจำ: 24.3M
   CGroup: /system.slice/etcd.service
           ââ1573 /usr/bin/docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data --name etcd my-aws-account.dkr.ecr eu-เหนือ-1.amazonaws.com...

18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.690Z","คนตัดไม้":"แพ","ผู้โทร":"...rm 2"}
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.691Z","ผู้โทร":"etcdserver/server..."3.5"}
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.693Z","ผู้โทร":"สมาชิก/คลัสเตอร์..."3.5"}
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.693Z","ผู้โทร":"etcdserver/server.go:2...
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.693Z","ผู้โทร":"api/capability.g..."3.5"}
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.693Z","ผู้โทร":"etcdserver/server..."3.5"}
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.693Z","ผู้โทร":"embed/serve.go:9...ests"}
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.695Z","ผู้โทร":"etcdmain/main.go...emon"}
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.695Z","ผู้โทร":"etcdmain/main.go...emon"}
18 ส.ค. 20:30:17 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1573]: {"level":"info","ts":"2021-08-18T20 :30:17.702Z","ผู้โทร":"embed/serve.go:1...2379"}
คำแนะนำ: บางบรรทัดเป็นวงรี ใช้ -l เพื่อแสดงแบบเต็ม

ฉันได้รับพฤติกรรมเดียวกันไม่ว่าจะฟัง Node IP (10.0.0.11) หรือ 127.0.0.1

ฉันสามารถเรียกใช้ etcd ในเครื่องโดยเริ่มจากบรรทัดคำสั่ง (และจะไม่สิ้นสุดหลังจาก 30 วินาที), กับ:

sudo docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data --name etcd-local \
my-aws-account.dkr.ecr.eu-north-1.amazonaws.com/etcd:v3.5.0 \
/usr/local/bin/etcd --data-dir=/etcd-data \
--ชื่อ etcd0 \
--advertise-client-url http://127.0.0.1:2379 \
--listen-client-url http://0.0.0.0:2379 \
--initial-advertise-peer-url http://127.0.0.1:2380 \
--listen-peer-url http://0.0.0.0:2380 \
--initial-cluster etcd0=http://127.0.0.1:2380

พารามิเตอร์ของ etcd คล้ายกับ เรียกใช้โหนดเดียว etcd - ectd 3.5 เอกสารประกอบ.

นี่คือส่วนที่เกี่ยวข้องของสคริปต์เริ่มต้นที่มีเป้าหมายเพื่อเรียกใช้ etcd:

ปริมาณนักเทียบท่า sudo สร้าง --name etcd-data

แมว <<EOF | sudo tee /etc/systemd/system/etcd.service
[หน่วย]
คำอธิบาย = ฯลฯ
หลังจาก = docker_ecr_login.service

[บริการ]
พิมพ์=แจ้ง
ExecStart=/usr/bin/docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data \
 --name etcd my-aws-account.dkr.ecr.eu-north-1.amazonaws.com/etcd:v3.5.0 \
 /usr/local/bin/etcd --data-dir=/etcd-data \
 --ชื่อ etcd0 \
 --advertise-client-url http://10.0.0.11:2379 \
 --listen-client-url http://0.0.0.0:2379 \
 --initial-advertise-peer-url http://10.0.0.11:2380 \
 --listen-peer-url http://0.0.0.0:2380 \
 --initial-cluster etcd0=http://10.0.0.11:2380
รีสตาร์ท = เมื่อล้มเหลว
รีสตาร์ทวินาที=5

[ติดตั้ง]
WantedBy=multi-user.target
อฟ

sudo systemctl เปิดใช้งาน etcd
sudo systemctl start เป็นต้น

เมื่อแสดงรายการคอนเทนเนอร์ทั้งหมดบนเครื่อง ฉันเห็นว่ามันกำลังทำงานอยู่:

sudo นักเทียบท่า ps -a
รหัสคอนเทนเนอร์ IMAGE คำสั่งสร้างสถานะชื่อพอร์ต
a744aed0beb1 my-aws-account.dkr.ecr.eu-north-1.amazonaws.com/etcd:v3.5.0 "/usr/local/bin/etcdâ¦" 25 นาทีที่แล้ว ออก (0) 24 นาทีที่แล้ว etcd

แต่ฉันสงสัยว่าไม่สามารถเริ่มใหม่ได้เนื่องจากชื่อคอนเทนเนอร์มีอยู่แล้ว

เหตุใดคอนเทนเนอร์ etcd จึงถูกยกเลิกหลังจาก ~ 30 วินาทีเมื่อเริ่มต้นจาก systemd ดูเหมือนว่าเริ่มต้นได้สำเร็จ แต่ systemd แสดงเฉพาะในสถานะ "เปิดใช้งาน" แต่ไม่เคยอยู่ในสถานะ "ใช้งาน" และดูเหมือนว่าจะถูกยกเลิกหลังจากผ่านไปประมาณ 30 วินาทีมีการส่งสัญญาณที่ขาดหายไปจากคอนเทนเนอร์ etcd docker ไปยัง systemd หรือไม่ ถ้าเป็นเช่นนั้น ฉันจะทำให้สัญญาณนั้นถูกต้องได้อย่างไร


อัปเดต:

หลังจากถอด รีสตาร์ท = เมื่อล้มเหลว คำแนะนำในไฟล์หน่วยบริการ ตอนนี้ฉันได้รับสถานะ: ล้มเหลว (ผลลัพธ์: หมดเวลา):

$ sudo systemctl สถานะ ฯลฯ
â etcd.บริการ - etcd
   โหลดแล้ว: โหลดแล้ว (/etc/systemd/system/etcd.service; เปิดใช้งาน; การตั้งค่าล่วงหน้าของผู้ขาย: ปิดใช้งาน)
   ใช้งานอยู่: ล้มเหลว (ผลลัพธ์: หมดเวลา) ตั้งแต่วันพุธที่ 2021-08-18 21:35:54 UTC; 5 นาทีที่แล้ว
  กระบวนการ: 1567 ExecStart=/usr/bin/docker run -p 2380:2380 -p 2379:2379 --volume=etcd-data:/etcd-data --name etcd my-aws-account.dkr.ecr.eu- north-1.amazonaws.com/etcd:v3.5.0 /usr/local/bin/etcd --data-dir=/etcd-data --name etcd0 --advertise-client-urls http://127.0.0.1: 2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://127.0.0.1:2380 --listen-peer-urls http://0.0.0.0: 2380 --initial-cluster etcd0=http://127.0.0.1:2380 (รหัส=ออกแล้ว สถานะ=0/สำเร็จ)
 PID หลัก: 1567 (รหัส=ออก สถานะ=0/สำเร็จ)

18 ส.ค. 21:35:54 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21 :35:54.332Z","ผู้โทร":"osutil/interrupt...ated"}
18 ส.ค. 21:35:54 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21 :35:54.333Z","ผู้โทร":"embed/etcd.go:36...379"]}
18 ส.ค. 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: คำเตือน: 2021/08/18 21:35:54 [หลัก] grpc: addrConn. createTransport ล้มเหลว ...กำลัง...
18 ส.ค. 21:35:54 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21 :35:54.335Z","ผู้โทร":"etcdserver/serve...6a6c"}
18 ส.ค. 21:35:54 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21 :35:54.337Z","ผู้โทร":"embed/etcd.go:56...2380"}
18 ส.ค. 21:35:54 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21 :35:54.338Z","ผู้โทร":"embed/etcd.go:56...2380"}
18 ส.ค. 21:35:54 น. ip-10-0-0-11.eu-north-1.compute.internal docker[1567]: {"level":"info","ts":"2021-08-18T21 :35:54.339Z","ผู้โทร":"embed/etcd.go:36...379"]}
18 ส.ค. 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal systemd[1]: ไม่สามารถเริ่มต้น etcd
18 ส.ค. 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal systemd[1]: Unit etcd.service เข้าสู่สถานะล้มเหลว
18 สิงหาคม 21:35:54 ip-10-0-0-11.eu-north-1.compute.internal systemd[1]: etcd.service ล้มเหลว
คำแนะนำ: บางบรรทัดเป็นวงรี ใช้ -l เพื่อแสดงแบบเต็ม
Score:1
ธง cn

อัปเดต: โพสต์ข้อมูลทดสอบและรวมการอัปเดตตามความคิดเห็นที่ได้รับ docker -d ไม่จำเป็นสำหรับการรวมระบบตามที่คิดไว้ในตอนแรก Type= การตั้งค่าตามที่ Michael ระบุไว้ดูเหมือนจะเป็นประสบการณ์ของฉัน สำคัญกว่าการถ่ายสถานะ daemonized ของบริการไปยังนักเทียบท่า ปัญหา OP ดูเหมือนจะเป็นผลข้างเคียงจากการไม่มีพื้นหลังดังที่ฉันได้อธิบายไปในตอนแรก พื้นหลังนี้ดูเหมือนไม่เกี่ยวข้องหลังจากทดสอบเพิ่มเติมแล้ว

โปรดทราบว่าอิมเมจ Amazon AWS ที่ใช้ใน OP ไม่ใช่สิ่งที่ฉันสามารถทดสอบหรือแก้ไขปัญหาได้โดยตรง ตัวอย่างที่ต่างกันสำหรับ etcd และ systemd แสดงไว้ที่นี่เพื่อช่วยในการกำหนดค่าระบบจุดสิ้นสุดที่คล้ายกับของฉัน รายละเอียดระบบ:

  • อูบุนตู 20.04 LTS
  • นักเทียบท่า 20.10.7
  • ฯลฯ 3.5.0

การกำหนดค่าระบบ

ฉันลงเอยด้วยไฟล์บริการ systemd ต่อไปนี้ โปรดทราบว่า Type=simple เนื่องจาก Michael แนะนำให้ชี้แจงประเด็นนี้ในการตอบกลับ (และเห็นได้ชัดว่าฉันเข้าใจปริศนาชิ้นนี้เอง) คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับประเภท systemd ได้ที่นี่:

https://www.freedesktop.org/software/systemd/man/systemd.service.html

เรื่องประเภท; ยิ่งไปกว่านั้น ความเข้าใจดั้งเดิมของฉันเกี่ยวกับประเภทแบบง่าย ๆ นั้นมุ่งเน้นไปที่การขาดการสื่อสารกลับไปที่ systemd ซึ่งทำให้ฉันเพิกเฉยต่อสิ่งที่เกี่ยวข้อง พฤติกรรม การตั้งค่าประเภทตอบสนองต่อการตอบสนองจากแอปพลิเคชันที่เรียก (ในกรณีนี้คือนักเทียบท่า)

การลบประเภทหรือการเพิ่มประเภทเป็นแบบง่ายจะส่งผลให้เกิดพฤติกรรมเดียวกันโดยไม่คำนึงถึง การกำหนดค่าต่อไปนี้ในการทดสอบของฉันทำงานได้อย่างน่าเชื่อถือ เช่นเดียวกับ -d ที่มีอยู่หรือไม่อยู่ในคำสั่ง docker run:

[หน่วย]
คำอธิบาย=คอนเทนเนอร์ Docker-etcd.service
Documentation=man:docker
ต้องการ = docker.service
ต้องการ=เครือข่าย.เป้าหมาย
After=network-online.target

[บริการ]
ExecStartPre=- /usr/bin/docker หยุด etcd
ExecStartPre=- /usr/bin/docker rm etcd
ExecStart=docker run --rm -d -p 2379:2379 -p 2380:2380 --volume=/home/user/etcd-data:/etcd-data --name etcd quay.io/coreos/etcd:v3 5.0 /usr/local/bin/etcd --data-dir=/etcd-data --name etcd --initial-advertise-peer-urls http://10.4.4.132:2380 --listen-peer-urls http: //0.0.0.0:2380 --advertise-client-urls http://10.4.4.132:2379 --listen-client-urls http://0.0.0.0:2379 --initial-cluster etcd=http:// 10.4.4.132:2380
ExecStop=/usr/bin/docker stop etcd -t 10
ExecRestart=/usr/bin/docker รีสตาร์ท etcd
KillMode=ไม่มี
เหลือหลังจากออก = 1
รีสตาร์ท = เมื่อล้มเหลว
ประเภท = ง่าย

[ติดตั้ง]
WantedBy=multi-user.target default.target

หมายเหตุ

  • เพิ่ม RemainAfterExit เนื่องจาก systemd จะพิจารณาว่าบริการออกจากระบบหลังจากเริ่มต้นหากไม่มีอยู่ การไม่มีบูลีนนี้ทำให้เกิดสถานการณ์ที่ดูเหมือนผิดพลาดโดยที่ นักเทียบท่า PS แสดงคอนเทนเนอร์ที่กำลังทำงานอยู่ แต่ คอนเทนเนอร์สถานะ systemctl-etcd แสดงว่าออกและไม่ใช้งาน
  • ไฟล์หน่วย systemd ค่อนข้างไม่ถูกต้องทางวากยสัมพันธ์ โดยทั่วไปจะใช้ %n สำหรับบรรทัด Exec เพื่ออ้างถึงชื่อบริการ (เช่นใน ...docker รีสตาร์ท %n); ฉันไม่ต้องการทำให้เกิดความสับสนเพิ่มเติมในขณะที่พยายามแก้ปัญหาของ OP ไม่ต้องพูดถึงว่าฉันใช้ etcd เป็นชื่อคอนเทนเนอร์นักเทียบท่า เทียบกับคอนเทนเนอร์-etcd เป็นชื่อบริการหน่วย
  • ExecStart ถูกยุบเป็นคำสั่งบรรทัดเดียว \ ไวยากรณ์มาตรฐานใช้ไม่ได้สำหรับฉัน และไม่ได้อ้างอิงคำสั่งเรียก etcd ไปยังคอนเทนเนอร์ การทดสอบของฉันเมื่อวานนี้ดูเหมือนจะทำงานได้ดี แต่การกำหนดค่าของวันนี้ไม่ได้ทำงานในลักษณะเดียวกับเมื่อวาน ดังนั้นฉันจึงทำการทดสอบและกำหนดค่าใหม่อีกครั้งเพื่อค้นหาสิ่งที่ดูเหมือนจะเสถียรที่สุดสำหรับฉัน
  • แน่นอน หากคุณกำลังจะใช้ docker rm ณ จุดใดก็ตาม คุณ ต้อง หรือรุนแรงมาก ควร ใช้การผูกเมานต์ตามที่ระบุไว้ใน OP และที่นี่ด้วย --volume โดยส่วนตัวแล้วฉันใช้ตำแหน่งพาธแบบเต็ม ทั้งหมดเก็บไว้ภายใต้ /srv แล้วผูกเมานต์ลงในคอนเทนเนอร์ ด้วยวิธีนี้ฉันจึงมีหนึ่งโฟลเดอร์ในการสำรองข้อมูลและสถานะของคอนเทนเนอร์จะมีหรือไม่ก็ไม่เกี่ยวข้องกัน

การยืนยัน

หลังจากอัปเดตไฟล์บริการ systemd ทำ daemon-reload ฯลฯ ฉันดำเนินการในคอนเทนเนอร์และรันคำสั่งทดสอบกับ etcd:

  • นักเทียบท่า exec -it etcd sh
  • etcdctl --endpoints=http://10.4.4.132:2379 รายชื่อสมาชิก

ผลลัพธ์

9a552f9b95628384, เริ่มต้นแล้ว, etcd, http://10.4.4.132:2380, http://10.4.4.132:2379, เท็จ
Michael Hampton avatar
cz flag
เหตุใด daemonize docker แทนที่จะใช้ `Type=simple` (ค่าเริ่มต้น) การเปลี่ยนแปลงนี้ให้ประโยชน์อะไร
cn flag
@MichaelHampton ทำไมคุณถึงต้องการใช้ Type=simple ?? คุณอ่านเอกสารแล้วหรือยัง?? อ้าง: "โปรดทราบว่านี่หมายความว่าบรรทัดคำสั่งเริ่มต้น systemctl สำหรับบริการอย่างง่ายจะรายงานความสำเร็จแม้ว่าจะไม่สามารถเรียกใช้ไบนารีของบริการได้สำเร็จก็ตาม" ดังนั้น เหตุผลที่ 1 ไม่ใช้ประเภทนี้ ทั้งไม่มีประสิทธิภาพและอาจทำให้เกิดปัญหากับผู้ที่อยู่ในบริการได้ประการที่สอง การใช้ -d กับ docker run เป็นวิธีหลักในการรัน containers daemonized ประการที่สาม นักเทียบท่าควบคุมคอนเทนเนอร์ ไม่ใช่ systemctl อย่างหลังเป็นเพียงการเรียกภูตที่ควบคุมพวกมัน อย่างน้อย 3 เหตุผล
Michael Hampton avatar
cz flag
ประเด็นไม่ได้อยู่ที่ระดับความรู้ของฉัน แต่เพื่อช่วยคุณปรับปรุงคำตอบของคุณ นี่เป็นข้อมูลที่ดีและควรรวมไว้เพื่อให้ผู้ที่มีประสบการณ์น้อยซึ่งอาจมีความคิดแบบเดียวกันได้รู้ว่าเหตุใดจึงไม่ควร
jp flag
สิ่งนี้ไม่ได้ผล บริการ etcd systemd ล้มเหลวด้วย: `ใช้งานอยู่: ล้มเหลว (ผลลัพธ์: โปรโตคอล)`
cn flag
@MichaelHampton ขอโทษ น้ำเสียงแปลข้อความได้ไม่ดี ดังนั้นฉันจึงถือว่าแย่ที่สุด ไม่เพียงเท่านั้น คำถามแรกของคุณคือคำตอบที่ถูกต้องจากประสบการณ์ของฉัน น่ารำคาญที่ฉันยังคิดไม่ออกว่าค่าของฟิลด์ Type กำลังทำอะไรอยู่ ขออภัยไว้ ณ ที่นี้ด้วย ฉันอัปเดตข้อความสำหรับความคิดเห็นทั้งสองที่นี่พร้อมข้อมูลและข้อค้นพบอื่น ๆ หวังว่า Jonas เวอร์ชันนี้จะช่วยให้คุณเข้าใกล้การทำงานมากขึ้นตามที่ต้องการ

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา