Bug#1059649: NTP does not keep accurate time on bookworm
Craig,
I'm sorry but I know absolutely nothing about that "systemd socket" mechanism.
I am an old hat
that grew up with init and hates systemd.
Maybe I have inadvertently broken something, I only know what I have written
before and that it does
not work for me without forcing the service to run as root instead of
Debian-snmp.
What exactly is going on now is unclear to me.
Rob
On 2024-02-02 06:13, Craig Small wrote:
> On Fri, 2 Feb 2024 at 08:54, Rob Janssen wrote:
>
> I am using systemd.
>
> Where are you seeing this error? The systemd socket is the thing that opens
> up the socket, so shouldn't matter what the snmptrapd process is running as.
>
> When I reboot, I get this:
> $ sudo ss -unlp | grep 162
> UNCONN 0 0 0.0.0.0:162 <http://0.0.0.0:162> 0.0.0.0:*
> users:(("systemd",pid=1,fd=83))
> UNCONN 0 0 [::]:162 [::]:*
> users:(("systemd",pid=1,fd=84))
> $ pgrep snmptrapd
>
> So systemd is listening to the socket and snmptrapd is not even running.
> After I send a trap:
> $ sudo ss -unlp | grep 162
> UNCONN 0 0 0.0.0.0:162 <http://0.0.0.0:162> 0.0.0.0:*
> users:(("snmptrapd",pid=7296,fd=3),("systemd",pid=1,fd=83))
> UNCONN 0 0 [::]:162 [::]:*
> users:(("snmptrapd",pid=7296,fd=4),("systemd",pid=1,fd=84))
> $ pgrep snmptrapd
> 7296
>
> Maybe the issue is that this system does not have IPv6 enabled? In
> sysctl.conf it has:
> net.ipv6.conf.all.disable_ipv6 = 1
>
> I added that and rebooted, it worked fine.
>
>
>
> That has effect on the default snmpd service as well, but I work around
> that by modifying the listen
> port in the config file.
> The snmptrapd.service file has "udp:162" and "udp6:162" args in the
> ExecStart but maybe these aren't used at all
> in this config? In bullseye I think it worked out of the box.
>
> In a way, they're used.
>
> In a proper systemd socket activation, the service doesn't need to know or
> define the ports it's listening to, they just get a bunch of file descriptors
> and use those.
>
> So we could have a command line in the service file with no ports and it
> looks like it works; but that is only because snmptrapd is sort-of looking
> for UDP port 162.
> If you change the socket definition to another port, say 164 you get this:
> Feb 02 15:57:37 elmo snmptrapd[9123]: couldn't open udp:162 -- errno 13
> ("Permission denied")
> Feb 02 15:57:37 elmo snmptrapd[9123]: couldn't open udp:162 -- errno 13
> ("Permission denied")
>
> system opens port 164, a trap to port 164 starts snmptrapd which not only
> listens to the systemd FD, but opens its own ports too running as a non-priv
> user.
> OK, so change the service definiton to listen to some port above 1024, it
> should be ok because it can open that port and use the systemd FD. For some
> reason
> it doesn't (as in it starts but there are no messages).
>
> What that means is the ports that are defined in the socket file need to
> match the ports in the service file. snmptrapd is shipped with that:
> $ grep 162 debian/snmptrapd.s*
> debian/snmptrapd.service:ExecStart=/usr/sbin/snmptrapd -LOw -f udp:162
> udp6:162
> debian/snmptrapd.socket:ListenDatagram=0.0.0.0:162 <http://0.0.0.0:162>
> debian/snmptrapd.socket:ListenDatagram=[::]:162
> debian/snmptrapd.socket:# ListenStream=0.0.0.0:162 <http://0.0.0.0:162>
> debian/snmptrapd.socket:# ListenStream=[::]:162
>
> It would be more friendly when snmpd and snmptrapd degrade gracefully to
> IPv4-only when there is no IPv6 on the system.
>
> I don't think its that.
>
> - Craig
>
Bug#1059649: NTP does not keep accurate time on bookworm
On 2024-02-01 22:09, Craig Small wrote:
> On Sat, 30 Dec 2023 at 06:15, Rob Janssen wrote:
>
> After the upgrade, the snmptrapd service no longer starts.
> The error message is: couldn't open udp:162 -- errno 13 ("Permission
> denied")
>
> Could you tell me how you start snmptrapd?
> There are two ways:
> The default systemd way. The socket is created with a snmptrap.socket and
> then passed onto the snmpdtrap server. I have tested this just now and it
> works fine with 5.9.4
> The init way. In this case snmptrapd starts as root and changes to
> Debian-snmp after binding to the sockets.
I am using systemd.
>
>
> To cover possible upgrade issues I removed and purged the snmptrapd
> package
> and re-installed it, but the new install suffered the same issue.
>
> What, specifically, are you doing to see this message? Running what you see
> in the service file on the command line won't work and will give this result.
At first I just upgraded a bullseye system where everything was working, to
bookworm, and it failed to start snmptrapd.
Then I did the uninstall/re-install of snmptrapd and it still failed.
Maybe the issue is that this system does not have IPv6 enabled? In sysctl.conf
it has:
net.ipv6.conf.all.disable_ipv6 = 1
That has effect on the default snmpd service as well, but I work around that by
modifying the listen
port in the config file.
The snmptrapd.service file has "udp:162" and "udp6:162" args in the ExecStart
but maybe these aren't used at all
in this config? In bullseye I think it worked out of the box.
It would be more friendly when snmpd and snmptrapd degrade gracefully to
IPv4-only when there is no IPv6 on the system.
Rob
Bug#1059649: Acknowledgement (NTP does not keep accurate time on bookworm)
Sorry, title of this bug report is wrong! (due to re-using an existing mail) Should be: snmptrapd does not start on bookworm
Bug#1059649: NTP does not keep accurate time on bookworm
Package: snmptrapd
Version: 5.9.3+dfsg-2
I upgraded a system from bullseye to bookworm.
It had snmptrapd installed.
Before the upgrade, all was OK.
After the upgrade, the snmptrapd service no longer starts.
The error message is: couldn't open udp:162 -- errno 13 ("Permission denied")
It appears that this is caused by the service being started as user Debian-snmp
and thus not being able to open privileged ports.
I could work around it by editing the systemd service file to run snmptrapd as
User=root but this is likely not what was intended.
To cover possible upgrade issues I removed and purged the snmptrapd package
and re-installed it, but the new install suffered the same issue.
Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)
On 6/7/23 10:54, Richard Laager wrote: > > I thought the sequences of events was this: > > 0. You are running ntp on bullseye. > 1. You upgrade to bookworm. This results in ntpsec being installed. > 2. You removed ntpsec. > 3. [The part I was asking about.] You reinstalled ntpsec. > 4. You found that ntpd was not syncing the clock. > 5. You switched to chrony. > > Was it this instead? > > 0. You are running ntp on bullseye. > 1. You upgrade to bookworm. This results in ntpsec being installed. > 2. You found that ntpd was not syncing the clock. > 3. You removed ntpsec. > 4. You switched to chrony. > > I'm trying to understand what happened with your ntp.conf. Upgrading from ntp > to ntpsec should result in your existing /etc/ntp.conf being copied to > /etc/ntpsec/ntp.conf by ntpsec.preinst. > It was the second scenario. As usual during upgrade I got those messages "you changed this config file, do you want to keep it or use the maintainers version", then I normally select "keep" every time (the default) and afterwards I do a "find / -name '*.dpkg-*'" to find all the new config files, review the diffs, and modify the new version with the same changes I made to the previous one. (in this case to remove the pool servers and add my own) So it was basically running with default config, except that I added two of my own servers and removed the pool servers. I do it this way to avoid situations where new default files are better and/or required with new packages, and I do not want to keep my old config all the time.
Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)
On 6/7/23 10:13, Richard Laager wrote: > On 2023-06-07 02:37, Rob Janssen wrote: >> Yes I was using the "ntp" package before. >> I have upgraded and it installed "ntpsec". I tried to remove it as I have >> no need >> for the "security" part but it removed "ntp" as well. > > And then you presumably reinstalled it. Did this result in you starting over > with a default ntp.conf, where you then manually removed (or commented out) > the pool lines and added your server lines? No, then I removed everything and installed chrony. That resolved the problem so then I made a bugreport. > >> Please don't fall in the common trap of trying to make everything "top >> secure" and then making it >> unusable or causing problems for people that do not require that. > NTPsec is a fork of NTP. Most of the security benefit of NTPsec comes from > NTPsec simply removing and cleaning up decades of code cruft in NTP. NTPsec > is a drop-in replacement for NTP. Except that it isn't. Or at least the default configuration isn't. > > > Probably you should put that > > config line commented in the default config so people who like it can > > easily enable it. > > This configuration exists for correctness. If a given system has two time > sources and they disagree, which one is correct? There is no way to be sure. > If you have three sources, then you take whichever two agree. In my opinion it is not good to enforce such policy on the users of the package. I know very well how NTP works and what issues there may be, but indeed the NTP servers are local and I deem them sufficiently reliable FOR MY PURPOSE. It worked fine on bullseye, it failed on upgrade to bookworm. And the config line that is responsible for the problem has a comment that does not indicate at all that you want to remove it when you have fewer than 3 servers. Maybe change that, I would have noticed it when I reviewed the config diffs. I originally commented that it works ok on another machine and believed it may be due to the VMware/Physical difference, but that wasn't the cause: that other machine was on another network and happend to have 3 servers configured. But I commented that line now (I do not want time sync to fail because one of the servers is unavailable!)
Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)
Yes I was using the "ntp" package before. I have upgraded and it installed "ntpsec". I tried to remove it as I have no need for the "security" part but it removed "ntp" as well. It looks like "ntp" is only a dummy package. I am in the process of upgrading a couple of systems so I will likely encounter this again and then will try to remove the "tos minclock 4 minsane 3". Please don't fall in the common trap of trying to make everything "top secure" and then making it unusable or causing problems for people that do not require that. Probably you should put that config line commented in the default config so people who like it can easily enable it. Rob On 6/7/23 05:18, Richard Laager wrote: > The answer is so obvious as soon as someone said it! > > The default "minsane" is "3" (see "tos minclock 4 minsane 3" in > /etc/ntpsec/ntp.conf). Try commenting out that line, or if that doesn't work, > set both to "1". >
Bug#1036821: Acknowledgement (NTP does not keep accurate time on bookworm)
status before I removed ntp: root@**-video:~# ntpq -p remote refid st t when poll reach delay offset jitter === +router.**.** 216.239.35.4 2 u 50 64 377 0.3705 -1604.11 1.2697 +**-linux.**.** 35.73.197.144 2 u 44 64 377 0.4070 -1604.26 1.2953 root@**-video:~# ntpq -p remote refid st t when poll reach delay offset jitter === +router.**.** 216.239.35.4 2 u 51 64 377 0.3606 -1623.06 1.2701 +**-linux.**.** 44.137.41.102 2 u 34 64 377 0.4630 -1623.29 1.2684
Bug#1036821: NTP does not keep accurate time on bookworm
Package: ntpsec Version: 1.2.2+dfsg1-1 I upgraded a system running on VMware from bullseye to bookworm. It had a simple NTP setup with two local servers (no pool servers). Before the upgrade, all was OK. After the upgrade, the system does not keep accurate time. It is synced, but it hovers at a ~1300 msec offset from the servers. I have rebooted the system and restarted ntpd, left it running for several days, but problem remains. On another system that runs on a physical machine, all is OK. No timesync is configured on VMware. I removed ntp+ntpsec and installed chrony. Timesync is OK now.
Bug#981802: squid starts too early with systemd
Package: squid Version: 4.6-1+deb10u4 Severity: normal Dear Maintainer, When squid is installed on a buster system with systemd and a DNS resolver, the squid proxy appears to be started too early. I use bind9 as a DNS server/resolver and have 127.0.0.1 configured in /etc/resolv.conf and in the squid configuration files. When configuration items like access lists refer to DNS names, the squid proxy fails to start on reboot and messages are logged that resolving DNS names failed. When the service is then started manually it runs fine. It appears to be a race condition caused by starting squid too early, when bind9 is not yet ready to handle requests. I am not sufficiently proficient in systemd configuration to properly work around this, so I worked around it the crude way by setting: ExecStartPre=/usr/bin/sleep 10 in the squid.service file. The ExecStartPre=/usr/sbin/squid --foreground -z that is there is only required the first time squid is started but I guess systemd lacks the capability to only do this when /var/spool/squid has not yet been populated. -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages squid depends on: ii adduser 3.118 ii libc62.28-10 ii libcap2 1:2.25-2 ii libcom-err2 1.44.5-1+deb10u3 ii libdb5.3 5.3.28+dfsg1-0.5 ii libdbi-perl 1.642-1+deb10u1 ii libecap3 1.0.1-3.2 ii libexpat12.2.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4+deb10u5 ii libgssapi-krb5-2 1.17-3+deb10u1 ii libkrb5-31.17-3+deb10u1 iu libldap-2.4-22.4.47+dfsg-3+deb10u5 ii libltdl7 2.4.6-9 ii libnetfilter-conntrack3 1.0.7-1 ii libnettle6 3.4.1-1 ii libpam0g 1.3.1-5 ii libsasl2-2 2.1.27+dfsg-1+deb10u1 ii libstdc++6 8.3.0-6 ii libxml2 2.9.4+dfsg1-7+deb10u1 ii logrotate3.14.0-4 ii lsb-base 10.2019051400 ii netbase 5.6 ii squid-common 4.6-1+deb10u4 Versions of packages squid recommends: ii ca-certificates 20190110 ii libcap2-bin 1:2.25-2 Versions of packages squid suggests: pn resolvconf pn smbclient pn squid-cgi pn squid-purge pn squidclient pn ufw pn winbind -- Configuration Files: /etc/squid/squid.conf changed [not included] -- no debconf information
