No match for argument ntp error unable to find a match ntp

↓
Содержание статьи
↓

Another app is currently holding the yum lock; waiting for it to exit…The other application is: yum

Вы пытаетесь воспользоваться yum и получаете ошибку

Another app is currently holding the yum lock; waiting for it to exit…
The other application is: yum
Memory : 96 M RSS (419 MB VSZ)
Started: Fri Mar 19 03:11:06 2021 — 7:44:44 ago
State : Sleeping, pid: 6217

Обратите внимание на pid (Process ID)

В данном примере pid равен 6217 — выясним что это за процесс с помощью команды ps

ps -ef | grep 6217

root 6217 6215 0 03:11 ? 00:01:18 /usr/bin/python /bin/yum -y install system_latest.rpm
root 6259 6217 0 03:12 ? 00:00:00 /bin/sh /var/tmp/rpm-tmp.3TcCYA 2
andrei 30392 29844 0 10:58 pts/0 00:00:00 grep —color=auto 6217

UID PID PPID C STIME TTY TIME CMD
root 6217 6215 0 03:11 ? 00:01:18 /usr/bin/python /bin/yum -y install system_latest.rpm
root 6259 6217 0 03:12 ? 00:00:00 /bin/sh /var/tmp/rpm-tmp.3TcCYA 2

Чтобы освободиться от процесса 6217 воспользуемся командой kill

sudo kill -9 6217

ps -ef | grep 6215

root 6215 6114 0 03:11 ? 00:00:00 sudo -S yum -y install system_latest.rpm

ps -ef | grep 6114

andrei 6114 1 0 03:10 ? 00:00:00 bash -c sudo ntpdate -u 0.fi.pool.ntp.org; sudo yum -y update; sudo yum -y upgrade; sudo -S yum -y install system_latest.rpm

Вот мы и добрались до самого первого вызова yum из моего скрипта. Точно также можно пойти вперёд.

There are unfinished transactions remaining. You might consider running yum-complete-transaction, or «yum-complete-transaction —cleanup-only» and «yum history redo last», first to finish them. If those don’t work you’ll have to try removing/installing packages by hand (maybe package-cleanup can help).

yum-complete-transaction

yum-complete-transaction —cleanup-only

[Errno 28] No space left on device: ‘//var/lib/yum/rpmdb-indexes/conflicts.tmp’

I have a setup with a host and a client which had that error.

The host used to work, it’s a VM and somehow it break on my last reboot. Now it has a hard time to keep time in the «Default» paravirtualization. Instead I have to use the «Minimal» version which doesn’t work as well (it takes forever to reboot because it has issues with time…)

The issue is that if the NTP server is not able to properly synchronize, then it gives up and «disconnect» itself.

Here is an example of a well behaved NTP server:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 1.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.008
 2.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.008
 3.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.008
 ntp.ubuntu.com  .POOL.          16 p    -   64    0    0.000    0.000   0.008
+23.175.208.10   239.9.71.195     2 u  845 1024  377   83.321   -1.074   2.255
+66.220.9.122    .CDMA.           1 u    4 1024  377   15.626   -1.183   2.644
+50.205.244.107  50.205.244.27    2 u  980 1024  377   65.114   -1.463   3.575
+173.255.215.209 80.72.67.48      3 u 1012 1024  377   16.956   -0.740   1.862
*163.237.218.19  .GPS.            1 u 1016 1024  377   63.002   -1.160   3.213
-91.189.89.198   17.253.34.253    2 u  616 1024  377  150.713    1.133   2.524

What we notice is an entry marked .GPS. which has an asterisk (*) in the first column. That means that time server is the used currently used to adjust your computer’s time.

If there are no line with the *, then the NTP server is either not yet ready (it takes about 20 seconds on startup) or it tried to synchronize and wasn’t able to. The ntpdate tests will fail with:

ntpdate[1234]: no server suitable for synchronization found

whenever either of these states are found.

In case of a VM, you are not really supposed to use an NTP server. I have to because I’m virtualizing a system which uses an NTP server and it’s very important in that simulation. You can have very similar issues with a VM as with a normal host, but the VM added the VirtualBox extra code… (additional details).

In case of a Host, there are three main issues:

1. In most cases, you have a firewall which blocks port 123. Note that this is UDP so the data has to go out and come back in.
2. The name of the time servers is invalid (unlikely if you kept the default).
3. Your hardware clock is defective (I never had such a problem, but I’ve heard of such—so it is really rare).

To test my firewall, I add LOG entries to tell me whether a hit is blocked. So before a DROP or REJECT rule, I place a LOG rule with the same parameters. That allows me to look at the logs and see whether certain hits are blocked.

As a side note, on my end I send the iptables logs to a separate file

# /etc/rsyslog.d/01-iptables.conf
:msg,contains,"[iptables] " /var/log/iptables/iptables.log
& stop

This way I can avoid the clutter in the /var/log/syslog and quickly find issues. The "[iptables] " works because I prefix my LOG messages with that string:

-A INPUT -i lo -j LOG --log-prefix "[iptables] reject_lo(in): " --log-uid
-A INPUT -i lo -j REJECT

If you can test without a firewall first, great, because that would be a lot faster to determine whether your firewall is the culprit. If you’re not running any services on your computer, then that’s safe:

$ sudo iptables -F