Điểm:1

Khắc phục sự cố đồng bộ hóa NTP trong máy chủ VirtualBox Linux

lá cờ cn

Tôi có một thiết lập khá đơn giản khi tôi có hai máy tính:

Máy tính A. có thiết lập NTP bình thường và sử dụng các nguồn Internet tiêu chuẩn (Theo Ubuntu) để xác định thời gian. Nó cũng cho phép truy vấn trên IP 10.0.2.0/24:

hạn chế 10.0.2.0 mặt nạ 255.255.255.0 nomodify notrap

Máy tính B. có thiết lập NTP bình thường, ngoại trừ tất cả các nguồn được thay đổi để sử dụng 10.0.2.1 (là Máy tính A).

Thỉnh thoảng, Máy tính A nhận được tín hiệu Nụ hôn thần chết từ một trong các nguồn của nó. Kết quả là, nó giết chết hoàn toàn NTP của Máy tính B (tức là có vẻ như KoD được truyền trực tiếp).

Có cách nào để biết trạng thái của máy chủ NTP về việc liệu nó có gửi tin nhắn KoD hay không? (còn nữa, làm cách nào để thoát khỏi tình trạng đó? Khi tôi nhìn vào nó, tất cả các địa chỉ IP được hiển thị trong nhật ký đều không được máy chủ sử dụng?! vì vậy tôi không hiểu tại sao nó cứ khăng khăng gửi KoD cho máy khách của mình) .


Tôi đã tìm thấy hai điều cho đến nay:

  1. ntpq

    tôi có thể chạy ntpq như vậy:

     ntpq -pn
    

    Khi máy chủ NTP hoạt động, tôi có thể thấy dấu hoa thị phía trước địa chỉ IP mà máy tính hài lòng. Trong trường hợp của tôi, tất cả các cờ trạng thái (cột đầu tiên +, -, *, #, v.v.) đều biến mất. Theo như tôi biết, điều đó có nghĩa là dịch vụ NTP không hài lòng và không có đồng bộ hóa nào được thực hiện.

    Đây là một ví dụ khi nó vẫn hoạt động (tức là có các cờ trong cột đầu tiên):

          từ xa refid st t khi cuộc thăm dò đạt độ trễ bù jitter
     ================================================================= ============================
      10.0.2.255 .BCST. 16 B - 64 0 0.000 0.000 0.000
     #51.77.203.211 134.59.1.5 3 u 4 64 1 171.248 -743.64 691.917
     +72.5.72.15 216.218.254.202 2 u 2 64 1 19.223 -778.34 686.200
     +159.69.25.180 192.53.103.103 2 u 3 64 1 237.733 -775.41 701.376
     +173.0.48.220 43.77.130.254 2 u 2 64 1 35.489 -778.85 669.187
      38.229.56.9 172.16.21.35 2 u 31 64 1 153.976 -268.90 122.557
     +137.190.2.4 .PPS. 1 u 31 64 1 93.797 -253.69 116.289
     +150.136.0.232 185.125.206.71 3 u 35 64 1 95.667 -178.19 114.912
      94.154.96.7 194.29.130.252 2 u 31 64 1 237.560 -231.88 107.230
     +162.159.200.123 10.4.1.175 3 u 34 64 1 16.246 -199.68 115.561
     *216.218.254.202 .CDMA. 1 u 35 64 1 52.906 -193.84 131.148
      91.189.91.157 132.163.96.1 2 u 45 64 1 87.772 -5.716 0.000
     +204.2.134.163 44.24.199.34 3 u 34 64 1 16.711 -199.12 116.777
     +74.6.168.73 208.71.46.33 2 u 35 64 1 69.772 -189.21 128.119
      91.189.89.199 17.253.34.123 2 u 45 64 1 165.471 -3.708 0.000
     +216.229.0.49 216.218.192.202 2 u 35 64 1 71.437 -178.94 97.505
      91.189.89.198 17.253.34.123 2 u 44 64 1 172.852 -17.899 0.000
    
  2. ntpdate -q <ip>

    Các ntpdate lệnh sẽ thực sự cho tôi biết liệu NTP có chấp nhận các gói tin hay không. Điều này là do nó đưa ra thông báo lỗi nếu không:

     $ Sudo ntpdate -q 10.0.2.1
     máy chủ 10.0.2.1, tầng 4, độ lệch 5.194725, độ trễ 0,02652
     21 tháng 7 15:22:48 ntpdate[13086]: không tìm thấy máy chủ phù hợp để đồng bộ hóa
    

    Điều này xảy ra sau một thời gian ngắn khi máy chủ chính của tôi bị mất * trạng thái trên một máy chủ, lần đầu tiên rất vui khi được đồng bộ hóa với...

Bây giờ... tôi vẫn cần hiểu mình phải làm gì để khắc phục sự cố này...


Điều này có thể hữu ích, đây là nhật ký về khởi động lại từ khởi động lại đầy đủ:

Ngày 21 tháng 7 18:29:13 hạt nhân vm-ve-ctl: [ 434.275481] kiểm toán: type=1400 kiểm toán(1626917353.636:43): apparmor="DENIED" operation="open" profile="/usr/sbin/ntp
d" name="/snap/bin/" pid=3896 comm="ntpd" request_mask="r" bị từ chối_mask="r" fsuid=0 ouid=0
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3896]: ntpd [email protected] (1): Bắt đầu
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3896]: Dòng lệnh: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 126:129
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: proto: precision = 0,190 usec (-22)
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Không thể mở tệp nhật ký /var/log/ntp.log: Quyền bị từ chối
Ngày 21 tháng 7 18:29:13 vm-ve-ctl kernel: [ 434.291490] audit: type=1400 audit(1626917353.652:44): apparmor="DENIED" operation="capable" profile="/usr/sbin/
ntpd" pid=3901 comm="ntpd" khả năng=1 capname="dac_override"
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: tệp bước nhảy giây ('/usr/share/zoneinfo/leap-seconds.list'): chữ ký băm tốt
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: tệp bước nhảy giây ('/usr/share/zoneinfo/leap-seconds.list'): đã tải, hết hạn=2021-12-28T00:00:00Z lần cuối =2017-01-01T
00:00:00Z củas=37
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Nghe và thả vào 0 v6wildcard [::]:123
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Nghe và thả vào 1 v4wildcard 0.0.0.0:123
21/07 18:29:13 vm-ve-ctl ntpd[3901]: Nghe bình thường trên 2 lo 127.0.0.1:123
21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Nghe bình thường trên 3 enp0s3 192.168.2.120:123
21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Nghe bình thường trên 4 enp0s8 10.0.2.1:123
21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Nghe bình thường trên 5 lo [::1]:123
21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Nghe bình thường trên 6 enp0s3 [fe80::a00:27ff:fe25:38ff%2]:123
21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Nghe bình thường trên 7 enp0s8 [fe80::a00:27ff:fe35:c30b%3]:123
Ngày 21 tháng 7 18:29:13 vm-ve-ctl ntpd[3901]: Lắng nghe ổ cắm định tuyến trên fd #24 để cập nhật giao diện
Ngày 21 tháng 7 18:29:14 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 51.77.203.211
Ngày 21 tháng 7 18:29:15 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 159.69.25.180
Ngày 21 tháng 7 18:29:15 vm-ve-ctl ntpd[3901]: Mời nhóm máy chủ 72.5.72.15
Ngày 21 tháng 7 18:29:16 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 198.251.86.68
Ngày 21 tháng 7 18:29:16 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 173.0.48.220
Ngày 21 tháng 7 18:29:16 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 38.229.56.9
Ngày 21 tháng 7 18:29:17 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 150.136.0.232
Ngày 21 tháng 7 18:29:17 vm-ve-ctl ntpd[3901]: Mời nhóm máy chủ 94.154.96.7
Ngày 21 tháng 7 18:29:17 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 137.190.2.4
Ngày 21 tháng 7 18:29:18 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 162.159.200.123
Ngày 21 tháng 7 18:29:18 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 216.218.254.202
Ngày 21 tháng 7 18:29:18 vm-ve-ctl ntpd[3901]: Mời nhóm máy chủ 91.189.91.157
Ngày 21 tháng 7 18:29:19 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 91.189.89.199
Ngày 21 tháng 7 18:29:19 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 74.6.168.73
Ngày 21 tháng 7 18:29:19 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 204.2.134.163
Ngày 21 tháng 7 18:29:20 vm-ve-ctl ntpd[3901]: Mời máy chủ nhóm 91.189.89.198
Ngày 21 tháng 7 18:29:20 vm-ve-ctl ntpd[3901]: Mời gọi máy chủ nhóm 216.229.0.49
Ngày 21 tháng 7 18:29:20 vm-ve-ctl ntpd[3901]: Mời nhóm máy chủ 2604:ed40:1000:1711:d862:f5ff:fe4e:41c4
Ngày 21 tháng 7 18:29:21 vm-ve-ctl ntpd[3901]: nhận: Dấu thời gian gốc không mong muốn 0xe4a34871.ac57f05d không khớp với aorg 0000000000.00000000 từ [email protected] xmt 0xe4a34871.65648c54

Tôi không biết chính xác khi nào nó bắt đầu trở nên tồi tệ. Tôi cũng đã thấy những điều sau đây mà tôi nghĩ có thể liên quan đến nó (tức là khi điều đó xảy ra, IP tương ứng sẽ bị xóa khỏi danh sách!), nhưng hiện tại nó đã rất tệ và không có lỗi như vậy xảy ra trong lần chạy cuối cùng của tôi.

Ngày 21 tháng 7 18:08:57 vm-ve-ctl ntpd[9764]: 92.243.6.5 local addr 192.168.2.120 -> <null>

Lưu ý: 192.168.2.120 là IP của máy tính bị lỗi. Nó là một VirtualBox. Nó đã hoạt động được nhiều tháng... tuy nhiên, có thể có gì đó đã thay đổi khiến nó không hài lòng.

tôi đã tìm thấy bài này về một vấn đề với ... -> <null> thông điệp. Tuy nhiên, tôi nghĩ rằng chúng tôi có phiên bản mới hơn trên Ubuntu 18.04:

Phiên bản khuyến nghị tối thiểu của SUSE: ntp-4.2.8p7-11.1
Phiên bản Ubuntu 18.04: 1:4.2.8p10+dfsg-5ubuntu7.3


Để đề phòng, tôi đã cố gắng kết nối máy ảo với máy chủ và tôi vẫn nhận được một khoản chênh lệch và jitter lớn. Điều gì có thể đã thay đổi?!

     từ xa refid st t khi cuộc thăm dò đạt độ trễ bù jitter
================================================================= ============================
 10.0.2.10 .POOL.         16 tr - 64 0 0.000 0.000 0.000
 10.0.2.10 132.163.97.6 2 u 54 64 3 0.457 -5254.2 3917.68

Theo yêu cầu của Paul Gear, đây là đầu ra của ntpq với các chi tiết bổ sung:

$ ntpq -ncrv
associd=0 status=0028 jump_none, sync_unspec, 2 sự kiện, no_sys_peer,
version="ntpd [email protected] (1)", bộ xử lý="x86_64",
system="Linux/4.15.0-151-generic", bước nhảy vọt=00, tầng=4, độ chính xác=-23,
rootdelay=17.930, rootdisp=5019.260, refid=173.255.215.209,
reftime=e4a44f7a.1c2ec778 Thứ năm, ngày 22 tháng 7 năm 2021 13:11:38.110,
clock=e4a45030.c8a4b259 Thứ năm, ngày 22 tháng 7 năm 2021 13:14:40.783, ngang hàng=0, tc=6,
mintc=3, offset=-109.527915, frequency=-1.707, sys_jitter=0.000000,
clk_jitter=38.724, clk_wander=0.000, tai=37, Leapsec=201701010000,
hết hạn=202112280000

Dưới đây là danh sách các đồng hồ có sẵn và đồng hồ hiện đang được sử dụng:

$ grep . /sys/devices/system/clocksource/clocksource*/[ac]*clocksource
/sys/devices/system/clocksource/clocksource0/available_clocksource:kvm-clock tsc acpi_pm 
/sys/devices/system/clocksource/clocksource0/current_clocksource:kvm-clock

Và cuối cùng, các dmesg đầu ra về quá trình lựa chọn nguồn đồng hồ:

$dmesg | nguồn đồng hồ grep
[ 0,000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0,000000] clocksource: tinh chế-jiffies: mặt nạ: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.283117] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 1.161844] clocksource: Đã chuyển sang clocksource kvm-clock
[ 1.208316] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 2.329228] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1db81a3240f, max_idle_ns: 440795250379 ns
Paul Gear avatar
lá cờ cn
Giả sử rằng đầu ra `ntpq -np` đầu tiên của bạn là từ máy tính A, có vẻ như nó có đồng hồ không chính xác (mặc dù NTP đã không chạy trong một thời gian dài nên rất khó để biết chắc chắn). Có vẻ như bạn có thể không có nguồn đồng hồ tốt nhất được định cấu hình để chạy trong máy ảo đó. `ntpq -ncrv` hiển thị gì sau khi NTP đã chạy được ít nhất 15 phút? Ngoài ra, `grep . /sys/devices/system/clocksource/clocksource*/[ac]*clocksource; dmesg | chương trình grep clocksource`?
lá cờ cn
@PaulGear Tôi đã chuyển ảo hóa song song sang **Tối thiểu** và điều đó đã làm cho nó hoạt động. Tôi quay lại **Mặc định** và gặp vấn đề tương tự.Tôi có một liên kết trong câu trả lời về nơi tôi tìm thấy giải pháp và thông tin chi tiết về giải pháp đó. Tôi vẫn thêm đầu ra như bạn hỏi ở đây. Tôi sẽ kiểm tra đồng hồ nào được sử dụng trong **Tối thiểu** và cũng đăng đồng hồ đó.
Điểm:1
lá cờ cn

Có vẻ như tôi đã tìm thấy một giải pháp. Tuy nhiên, tôi không chắc tại sao nó lại hoạt động trước đây.

Sau nhiều lần tìm kiếm, tôi đã tìm thấy vé VirtualBox này:

https://www.virtualbox.org/ticket/15179

nói rằng bạn không nên sử dụng ntpd bởi vì VM đã giữ thời gian bằng cách sử dụng thời gian của Máy chủ để điều chỉnh VM đồng hồ ảo.

Tuy nhiên, ngay cả khi không có ntpd đang chạy, đồng hồ của máy ảo của tôi bị tắt và sẽ bật lên trong khoảng  ± 30 giây trong một khoảng thời gian ngắn.

Đọc thêm bài đăng đó, họ đề nghị điều chỉnh cài đặt ảo hóa song song thành "Không". Điều đó dường như không làm việc cho tôi. Tôi đã khởi động lại VM và nó bị kẹt. Vì vậy, thay vào đó, tôi đã thử với "Tối thiểu" và bây giờ đồng hồ đang hoạt động. Các ntpq -np đầu ra trông tốt hơn rất nhiều:

Thứ năm, ngày 22 tháng 7 12:57:57 PDT 2021
     từ xa refid st t khi cuộc thăm dò đạt độ trễ bù jitter
================================================================= ============================
 1.ubuntu.pool.n .POOL. 16 tr - 64 0 0.000 0.000 0.008
 2.ubuntu.pool.n .POOL. 16 tr - 64 0 0.000 0.000 0.008
 3.ubuntu.pool.n .POOL. 16 tr - 64 0 0.000 0.000 0.008
 ntp.ubuntu.com .POOL. 16 tr - 64 0 0.000 0.000 0.008
+23.157.160.168 129.6.15.28 2 u 20 128 377 83.831 0.783 1.745
-104.131.139.195 163.237.218.19 2 u 28 128 377 20.162 3.622 1.451
+144.76.64.40 36.224.68.195 2 u 18 128 377 179.329 2.557 6.671
-159.89.86.140 192.5.41.40 2 u 126 128 377 87.016 3.094 1.385
-23.175.208.10 239.9.71.195 2 u 35 128 377 82.350 2.311 0.794
+206.82.16.3 47.187.174.51 2 u 127 128 377 84.683 1.385 0.753
+92.243.6.5 85.199.214.98 2 u 25 128 377 163.041 4.275 4.025
*200.160.7.186 .ONBR. 1 u 47 128 377 191.078 1.126 1.865
+51.255.197.148 217.91.44.17 2 u 96 128 367 154.201 1.225 4.742

Như chúng ta có thể thấy, Offset (tối đa 4,3) và Jitter (tối đa 6,7) là rất nhỏ so với những gì tôi nhận được trước đây. Bây giờ máy tính khác của tôi cũng hoạt động và có thể tự đồng bộ hóa với đồng hồ này. Độ trễ là khoảng 0,7, đối với tôi là đủ (trong trường hợp của tôi, đủ là 12,0 trở xuống).

LƯU Ý QUAN TRỌNG: Tôi đã khởi động lại máy ảo đó 2 hoặc 3 lần bằng cách sử dụng Tối thiểu, thời gian khởi động rất lâu. Vì vậy, tôi không khuyên bạn nên sử dụng chế độ này trừ khi đó là phương sách cuối cùng nếu bạn thực sự cần một đồng hồ hệ thống đang hoạt động. Nếu bạn có một giải pháp tốt hơn hiệu quả, tôi sẽ lắng nghe!


Để đề phòng, tôi muốn thấy sự khác biệt về nguồn đồng hồ trong Tối thiểu cách thức. Chúng tôi chỉ nhận được acpi_pm cái đồng hồ.

$ grep . /sys/devices/system/clocksource/clocksource*/[ac]*clocksource
/sys/devices/system/clocksource/clocksource0/available_clocksource:acpi_pm 
/sys/devices/system/clocksource/clocksource0/current_clocksource:acpi_pm

Bây giờ tôi đang tự hỏi liệu điều này có ảnh hưởng đến đồng hồ máy chủ hay không. Vì tôi cũng có ntp trên Máy chủ của mình nên tôi không nghĩ đây là vấn đề.

vidarlo avatar
lá cờ ar
NTP cố gắng xây dựng một hồ sơ về sự trôi dạt của đồng hồ cục bộ. Điều này giả định rằng đồng hồ hoạt động tốt và trôi theo kiểu tuyến tính. Khi bạn có một đồng hồ được đặt bởi một nguồn không xác định thành ntpd, nó sẽ bỏ cuộc - vì nó bước ngẫu nhiên theo những cách không thể giải thích được. Bạn có thể muốn đọc [câu hỏi và trả lời này](https://stackoverflow.com/questions/25041213/how-to-disable-virtualbox-time-sync-from-within-the-guest-at-runtime) tại SE dưới dạng tốt cho làm thế nào để vô hiệu hóa điều này.
lá cờ cn
@vidarlo À... `--disable-timesync` có lẽ là giải pháp. Nói như vậy, tôi chỉ thấy rằng đồng hồ mặc định sử dụng `kvm-clock` và chuyển sang `tsc` có lẽ sẽ tốt hơn về mặt "không trôi". Vẫn đang thử nghiệm nhiều thứ khác nhau ở đây.
vidarlo avatar
lá cờ ar
Đối với khối lượng công việc ảo hóa, hãy đồng bộ hóa máy chủ và để máy ảo lấy thời gian từ máy chủ. Dù sao thì độ trôi của đồng hồ cũng rất lớn do trình ảo hóa thực hiện việc lên lịch lại không xác định.
lá cờ cn
@vidarlo Tuy nhiên, trong trường hợp của tôi, tôi đang mô phỏng một ứng dụng cài đặt và chạy `ntpd` vì tôi cần một mạng cục bộ với thời gian rất chặt chẽ. Điều đó đang được nói, bằng cách nào đó, vấn đề rất dễ thấy trên máy ảo đó ngay cả khi không chạy ntp. Khá kỳ lạ. Nó đã hoạt động tốt trong gần một năm ...
Điểm:0
lá cờ cn

Được rồi, khá bất thường, tôi đang thêm câu trả lời thứ hai vì điều này giải thích 100% lý do tại sao bắt đầu bị hỏng. Trong vòng vài ngày sau khi tôi khởi động lại lần cuối, sẽ có một bản nâng cấp trình điều khiển NVidia. Sau đó, tôi bắt đầu VM của mình (tức là thứ tự ở đây rất quan trọng!)

Tôi không biết rằng môi trường 3D có thể bị thiếu và nếu không được tăng tốc, thì VM sẽ hoàn toàn hoạt động sai về đồng hồ/thời gian.

Lưu ý rằng tôi không nhìn thấy thực tế là môi trường 3D không khả dụng. Nó có thể đã được đề cập trong một số nhật ký, nhưng như một Tiêu chuẩn người dùng, tôi hoàn toàn bỏ lỡ phần đó.

Sau khi khởi động lại hoàn toàn (do bản nâng cấp NVidia yêu cầu), VM hoạt động bình thường trở lại. Không cần sử dụng Tối thiểu Tùy chọn. Tôi đặt máy ảo đó trở lại Mặc định và nó hoạt động hoàn hảo như trước đây.

Tôi hy vọng điều này sẽ giúp một số người bớt đau đầu trong 3 ngày ...

Đối với những người quan tâm, thay đổi đồng hồ cũng có thể hữu ích. Oracle có một trang hay về cách thay đổi nguồn đồng hồ. Cuối cùng, tôi đã kết thúc việc sử dụng apci_pm mà dường như giúp rất nhiều trong việc duy trì thời gian trong một thời gian dài.

# echo "acpi_pm" > /sys/devices/system/clocksource/clocksource0/current_clocksource

Bạn cũng có thể cập nhật các tham số khởi động của mình để mỗi lần khởi động, bạn sẽ nhận được nguồn đã chọn đó.

GRUB_CMDLINE_LINUX="... clocksource=acpi_pm"

(Tôi đã xóa các tham số không liên quan ở đây, đừng xóa chúng, chỉ cần thêm nguồn đồng hồ tham số; nó cũng có thể là biến trống trong lần đầu tiên bạn chỉnh sửa nó: GRUB_CMDLINE_LINUX="").

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.