Manjaro machine freezes when qbittorrent runs

[jamjar]

@Nachlese

… you might want to revise/shorten your log output above - there is several cifs mounts in there with username and password …

Thank you. But I don’t think I can do anything about that because this forum preserves all the edits. I can only hope nobody wants my movie files badly enough to get through to my LAN.

@Nachlese

But I don’t know what to do about it.

From that, I may presume you don’t believe disabling the avahi-daemon would have fixed that problem?

[Nachlese]

I have taken the liberty to edit/change the username and password to xxxx.

@jamjar

From that, I may presume you don’t believe disabling the avahi-daemon would have fixed that problem?

Yes - for whatever that is worth. Not much if anything, I think.

[tracyanne]

@jamjar

@Nachlese

there is several cifs mounts in there with username and password …

Thank you. But I don’t think I can do anything about that because this forum preserves all the edits

Just a note you can create credential file and store that somewhere safe. I store in /root.

you use it like this, in place of username and password

credentials=/root/mediacred

[linux-aarhus]

@jamjar

Host name conflict,

Please ensure that you have no duplicated host names on your network.

Read the hostname

hostnamectl

Change hostname

hostnamectl hostname <hostname>

You may need to reload the network - in network manager disconnect and then reconnect

[soundofthunder]

@jamjar

I was rash to think the problem first reported in Manjaro machine freezes when qbittorrent runs was fixed

The two topics have now been merged. This should make things a little easier to follow.

Regards.

[jamjar]

@linux-aarhus

Please ensure that you have no duplicated host names on your network.

Thank you. I did that with all my computers (physical or VM, Linux or Windows) and confirmed: no duplication of hostnames.

[linux-aarhus]

Mar 31 23:21:51 jar-d NetworkManager[627]: <info>  [1743430911.9066] hostname: hostname: using hostnamed
Mar 31 23:21:51 jar-d NetworkManager[627]: <info>  [1743430911.9067] hostname: static hostname changed from (none) to "jar-d"

What is the output from

 cat /etc/hostname

Based the quoted output from your journal I am guessing - the file is either missing or empty.

If that is so - please ensure there is a valid hostname in the file.

[jamjar]

@linux-aarhus

What is the output from

cat /etc/hostname

I got:

[luna@jar-d ~]$ cat /etc/hostname
jar-d

[linux-aarhus]

If the issue is network related - I suggest you disable IPv6 on the system.

The reason behind is the numerous errors with avahi daemon trying to assign IPv6 - it can be done from Network Manager the IPv6 tab - set Method: Disabled

Have you tried changing the vm network from dhcp to bridge ?

Perhaps disable avahi - I think it has been mentioned above somewhere

sudo systemctl disable --now avahi-daemon.service avahi-dnsconfd.service avahi-daemon.socket

[jamjar]

@Mirdarthos

Always provide the output for:

inxi --filter --verbosity=8

Then some system logs might help:

journalctl --priority=warning..crit --no-pager --boot=0

@soundofthunder

When/if it crashes, use the following command immediately after the next boot;

journalctl --boot=-1 --no-pager

Is there a version of one of these commands (or some other) I could run before the system crashes again, to see whether it was having trouble (i.e. generating such lines as Host name conflict, retrying with jar-d-3248 but somehow managing to stay up).

An ideal command would give me only the lines generated after the last crash and relating to some trouble the system was having.

[Nachlese]

@jamjar

An ideal command would give me only the lines generated after the last crash and relating to some trouble the system was having.

There are time stamps right in front of that commands

journalctl --boot=-1 --no-pager

output.

@jamjar

Is there a version of one of these commands (or some other) I could run before the system crashes again

You said it took some time before it “crashed”.
Get it inside that time frame …?

[soundofthunder]

@jamjar

Is there a version of one of these commands (or some other) I could run before the system crashes again, to see whether it was having trouble

I’m sure there is.

Some more Linux fun for you:

• systemd/Journal (Arch Wiki)

Regards.

[jamjar]

@Nachlese

You said it took some time before it “crashed”.
Get it inside that time frame …?

I am sorry. I thought the command was only for diagnosing a crash because that was the only time I ever used it. Thanks for actually answering my clueless questions.

@soundofthunder

@jamjar

Is there a version of one of these commands (or some other) I could run before the system crashes again, to see whether it was having trouble

I’m sure there is.

You’d already given me the command in your very first reply! Thanks.

journalctl --priority=warning..crit --no-pager --boot=0

@linux-aarhus

The reason behind is the numerous errors with avahi daemon trying to assign IPv6 - it can be done from Network Manager the IPv6 tab - set Method: Disabled

Thank you. After disabling avahi-daemon (following the last crash), I don’t seem to get any more lines similar to: Host name conflict, retrying with jar-d-3248.

Were there some other lines pointing to IPv6 as a potential culprit?

Another thing I’ve found out, my other Manjaro VMs (which do not have a torrent client running and never crash) are also quietly stacking up such lines as: Apr 03 12:23:09 jar-m avahi-daemon[653]: Host name conflict, retrying with jar-m-5705 (see the whopping 5705).

Maybe that line in the affected machine is not a clue to why it is crashing.

Of course, it’s also possible that it is the cause but does not have an opportunity to do its work when no torrent client is present.

[jamjar]

I seem to have stabilized my system (it has up- and downloaded torrents at greater than normal usage for some 12 days without crashing).

Toward that, I did the following three things (in the order presented), which I hesitate to call a “fix” (for reasons mentioned), but somebody might find them useful.

1. Resolve a hostname conflict as described in:

@jamjar

My /etc/hosts have (relevantly):

::1        localhost ip6-localhost ip6-loopback
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters
# This host address
127.0.1.1  jar-d
10.200.17.51    jar-d

–where 10.200.17.51 jar-d are the I.P. address and computer name of the VM in question.

Two circumstances confuse a causal analysis:

• The conflict had long predated a sudden increase in crashing incidence (every five minutes of active download at near ISP-maximum bandwidth), which prompted me to post here.
• The resolution of the conflict brought the incidence back to what it had been before (once every few days and not dependent on active download).

So I conclude that the conflict was probably the cause of the high incidence crashing but not of the low incidence crashing.

2. Give VM a low performance network adapter.

See: A way to choke network bandwidth used by qbittorrent during an integrity check?

But the fix was responding to a different problem.

3. Disable avahi-daemon:

@Mirdarthos

As far as I know, someone might know better than me, but as far as I know, Avahi doesn’t really seem necessary for you, so disable it:

sudo systemctl disable --now avahi-daemon

Which has ended the Mar 28 21:06:55 jar-d avahi-daemon[630]: Host name conflict, retrying with jar-d-2 type of warning in the journalctl log and also ended the low incidence crashing (for some 12 days at least).

But the following circumstance makes causation murky:

• All my other Manjaro machines have that type warning without crashing.

So we might have to say that an enabled avahi-daemon causes crashing only if a torrent client is running.

What was most useful to my investigation was this command:

@Mirdarthos

hen some system logs might help:

journalctl --priority=warning..crit --no-pager --boot=0

Where:

• The --priority=warning..err argument limits the output to warnings and errors only;
• --no-pager formats the output nicely for use here, on the forum;
• the --boot=0 argument limits the messages to be from the current boot.

I will continue to observe my system and, if it goes without incident for another couple weeks, choose a solution to close the post.