traceroute will only learn the IP address if it gets a response from the system. So in this case it's only going to work intermittently.

I suspect your traffic may be routed through two or more paths, one via a system that generates timout responses and one or more that don't. So it's a matter of chance whether you get a response.

But it's not a worry because your traffic is always passed on to later sites.

That's past my knowledge of networking. It seems to have only replied to 2 of the 61 test packets sent to it. But passed on all the packets sent to later links.

If you are really interested you could ping it and see how often it replies. But it's probably won't get you anywhere unless you ask the telco that owns it, who probably won't be interested because it's passing packets on OK.

host host39.181-89-51.telecom.net.ar should tell you it's IP address. But again that isn't likely to tell you anything useful.

Your telco may well have an equivalent on their website. Which they might be more willing to believe since it *should* only be going through their hardware to get to it. So they can't blame congestion on the internet between their kit and the site in question.

I had a period when I was getting bad performance from my connection. It showed up as ping'ing sites on the internet got lost and duplicate packets. I used traceroute to my telco's website, then pinged each hop to find out where the fault seemed to be (in my case the first hop past my router). But I hope you don't need to do that.

I just hover my mouse pointer over chopped URLs and the browser shows the full link on the bottom bar. By now it's a habit.

It also helps on web pages where the link doesn't match the visible text. Eg hover on the name of a poster.

A quck test gave me a clue (output truncated for brevity):

$ netstat -tulpen
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          15476      -                   
tcp        0      0 0.0.0.0:60799           0.0.0.0:*               LISTEN      105        14342      - 

And as root:

$ sudo netstat -tulpen
[sudo] password for chris: 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          15476      2240/exim4          
tcp        0      0 0.0.0.0:60799           0.0.0.0:*               LISTEN      105        14342      1343/rpc.statd  

So netstat can't find out the PID/Program name if it's not running as root unless the program that opened the socket is running as you.

Could the system be overheating? Check for dust etc in the CPU cooler, vents, etc. Going over the system with a vacuum cleaner can make quite a difference. As can removing obstructions to air flow etc.

You could run watch sensors in one window to see how hot the system is getting.

Or free -mt or vmstat to see how much paging it's doing.

It's worth learning about. Assuming you have the same userid on both your systems just try ssh laptop on the desktop or vice versa (replace "laptop" with the IP address of the laptop if you havn't set up DNS or /etc/hosts entries for it). Reply y (or yes) to the prompt about accepting the host key, then it should ask you for your password.

If it hangs for a bit then times out ping the target to check the IP address is right.

That should get you started. man ssh will tell you lot more if you need to know more. Eg about how to copy files between the systems with scp or sftp.

Try host deb.devuan.org which should get something like:

deb.devuan.org is an alias for deb.rr.devuan.org.
deb.rr.devuan.org has address 106.178.112.231
deb.rr.devuan.org has address 172.234.26.53
deb.rr.devuan.org has address 185.38.15.84
deb.rr.devuan.org has address 185.183.113.131
deb.rr.devuan.org has address 131.188.12.211
deb.rr.devuan.org has address 147.78.194.22
deb.rr.devuan.org has address 195.85.215.180
deb.rr.devuan.org has address 103.146.168.12
deb.rr.devuan.org has address 95.216.15.86
deb.rr.devuan.org has address 200.236.31.1
deb.rr.devuan.org has address 46.4.50.2
deb.rr.devuan.org has address 130.225.254.116
deb.rr.devuan.org has address 141.84.43.19
deb.rr.devuan.org has address 190.64.49.124
deb.rr.devuan.org has address 160.16.137.156
deb.rr.devuan.org has address 185.178.192.43
deb.rr.devuan.org has address 158.69.153.121
deb.rr.devuan.org has address 125.228.189.120
deb.rr.devuan.org has address 89.174.102.150
deb.rr.devuan.org has address 94.16.114.15
deb.rr.devuan.org has address 185.236.240.103
deb.rr.devuan.org has IPv6 address 2407:b6c0::12
deb.rr.devuan.org has IPv6 address 2a01:4f9:2a:fa9::2
deb.rr.devuan.org has IPv6 address 2801:82:80ff:8000::2
deb.rr.devuan.org has IPv6 address 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
deb.rr.devuan.org has IPv6 address 2001:878:346::116
deb.rr.devuan.org has IPv6 address 2001:4ca0:4300::1:19
deb.rr.devuan.org has IPv6 address 2800:a8:c001::a
deb.rr.devuan.org has IPv6 address 2001:e42:102:1704:160:16:137:156
deb.rr.devuan.org has IPv6 address 2607:5300:61:95f:7283:11d9:f86:e691
deb.rr.devuan.org has IPv6 address 2001:4190:801c:1::150
deb.rr.devuan.org has IPv6 address 2a03:4000:28:24c::
deb.rr.devuan.org has IPv6 address 2a0d:eb00:8006::acab
deb.rr.devuan.org has IPv6 address 240b:10:f00:1b00::240
deb.rr.devuan.org has IPv6 address 2a02:2a38:1:400:2a42:2a42:2a42:2a42
deb.rr.devuan.org has IPv6 address 2001:638:a000:1021:21::1
deb.rr.devuan.org has IPv6 address 2a0a:e5c0:10:3::6eeb
deb.rr.devuan.org has IPv6 address 2a01:9e40::180

Then ping deb.devuan.org and see if that gets a response. If it does you should be OK. If not your DNS settings or network must be faulty.

All I can think of is looking in /etc/rc.local (that gets called at the end of each runlevel, but normally does nothing).

Apart from that I've run out of ideas for what could be calling kmod. So I'd suggest ignoring the message, the script doesn't do anything when called with the stop parameter.

Exactly when does that message come out? Is it when you boot the system, log on, log off or shut it down?

less /etc/init.d/kmod should tell you what kmod is (unless all the comments are missing).

Try this:

ls -l /etc/rc?.d/*kmod*
lrwxrwxrwx 1 root root 14 May  9  2018 /etc/rcS.d/S09kmod -> ../init.d/kmod

You should get only 1 line, a symlink that tells the OS to run kmod start when bringing the system up. I suspect you have a stop link somewhere (it will be probably named something like K09kmod).

For belt and braces try ls -l /etc/rc?.d/ | grep kmod which searches the destination of the symlink. If still stuck grep meaningless /etc/rc?.d/* in case there is a stray copy of kmod somewhere.

cat /proc/cmdline should also show the boot command line. On my system it matches the entry for the last boot in /var/log/syslog

I would *assume* that a merged /usr would have moved everything in /sbin to /usr/sbin and replaced /sbin with a symlink to /usr/sbin (and similar for /bin, /lib, etc). But that's probably too simple for the designers to think of.