Posted in Linux

“Processing triggers for man-db” takes too much CPU time or disk I/O

Recently I found a problem: while apt upgrade, it’s always being stuck at “Processing triggers for man-db”. In fact, the process is still running, just too slowly.

I guess triggering man-db will take too much CPU time to finish so that it looks like being stuck. I didn’t monitor the disk I/O status, I guess it needs a number of disk I/O actions. If you’re using HDD, that would be slow.

Maybe there’s a bug. As far as I know, man-db problem exists in every Debian based Linux distribution, including Debian and Ubuntu. The earliest report I see is in 2012, and Debian 11, the latest stable Debian version, also has this problem.

Because triggering man-db is the last step of upgrade, it seems like organizing and concluding something. It doesn’t upgrade man-db package itself, so using apt-mark hold man-db command is useless.

Some tutorials says that remove the man-db package or delete the cache folder of man-db, it may cause other problems.

Posted in Linux, Network, Visual Studio Code, Windows

VS Code SSH remote connect to Linux Server (Real Solution)

First of all, forget the one who told you using Putty to generate the key, it’s outdated now.

Why? Because in the past, only Linux supports SSH so that Windows should use third party tool to realize SSH remote connection. But now Windows 10 supports native SSH Client, so you must get used to this one and avoid strange errors or wrongs.

Then, let’s see how to generate SSH key by native SSH Client. It’s easy. Open your local terminal (Linux or Windows) and execute:

ssh-keygen

In fact, though there is many options can be added, I only recommend one:

ssh-keygen -C username

Must be uppercase C and you can change the username to be any name you want to use, but that should be used to log in your Linux Server as its username later. It should be the same as your Linux username.

After you execute the command, you just follow the instructions on the screen. If you want not to overwrite the existing key files, change the default directory. If it suggests you to input Phrase, that can be empty, just enter directly.

When done, remember the default directory in the instruction just now? For Windows, you can cd into C:\Users\your_username\.ssh\; for Linux, you can cd into home/username/.ssh/.

Now you can see two files: id_rsa and id_rsa.pub.

pub means public, so its a public key. For the other with no extension, it’s a private key.

Here is the annoying question: where should I put them?

Well, if you look up on the internet and you will find too much information about that but you will be more confused.

Exactly, ssh-keygen is just a tool to generate keys, that’s all. It’s not about how to connect. So whatever you generate on Windows or Linux, Client or Server, that’s fine, don’t care about it. You just use a tool to generate two files.

But then the following question again is: So where should I put them indeed?

Well, maybe there is many theories behind the scene, but let me tell you the simple truth: client stores the private key and server stores the public key.

For example, you have PC A and PC B, you want to use PC A connect to PC B, so you should store the private key on PC A and store the public key on PC B.

But you should always make sure they are in a pair because you may have generated many key pairs before or later.

Why the server should store the public key? In fact, it’s easy to understand. The server will show the public key to anyone, but only allow connecting with who holds the private key. Due to the key stored on the server is public, so we called it public key.

Now let’s move on.

Now that we have known we should upload our public key on the server, let’s do it. If your client is Linux, thats easy, using:

 $ ssh-copy-id user@host

But if you are using Windows, ssh-copy-id should not work. So we need to understand what ssh-copy-id does.

Okay, we find a new file called authorized_keys. Go to your Linux server (use shell, SFTP or GUI), create that authorized_keys file under home/user/.ssh/ and copy the pub file contents (you can open it by VS Code) and paste into the new empty file. Save it.

In fact, id_rsa and id_rsa.pub is not necessary here

In case, reboot your Linux server now.

And now we should care about our path to store the private key. If you generate the keys on Windows directly, you should store it under C:\Users\username\.ssh\. If you generate it on Linux but you want to let it be stored on your Windows, you should download it from the Linux first. How to download it? I think SFTP is the best way. Use your SFTP tool to download it from Linux path home/username/.ssh and then store it under the same path on Windows.

Now we should check what we have done before we go on:

  1. we generate SSH Keys in a pair using ssh-keygen
  2. we store the private key on our client Windows PC (under C:\Users\your_username\.ssh\)
  3. we store the public key on our server Linux PC (under home/username/.ssh/authorized_keys)

Now let’s move on.

Open your VS Code, install SSH extensions in Extension Store. After installation, you will find a new icon on the side bar. Click it.

You can add new connection by “+” button. Follow the instruction on the top popped out dialog. After done, click ⚙ button. It will let you choose the path where SSH key files store. Then you will open a config file.

You can edit something here:

Host will change the UI display on the panel.

Hostname: the IP address or URL of your server.

User: should be the same as ssh-keygen -C username.

Port: the SSH port. Default is 22.

If you are using Virtual Machine like VirtualBox, you need to forward your Virtual Machine port (like 22) to the Host Machine port (like 12345).

IdentityFile: if you don’t add this option, VS Code will use the default ssh path (C:\Users\username\.ssh). But if you have many SSH key files to store in different paths, you should tell VS Code where is that file. On Windows, the “\” should be changed to “\\”.

Edit this file as your condition and save it.

Sometimes, there’s a problem on connecting a server by a forwarded port. You need to use the server real IP directly. You need use “ifconfig” command on your server shell screen. If it doesn’t work, just use apt install net-tools to get it. Type ifconfig, you will see server IP on the shell screen. Use this IP in your vscode config file, and set Port as 22(or delete Port line because the default port is 22).

Before we go, a small thing we need to deal with: go to C:\Users\username\.ssh, you will find a file called known_hosts. Delete it, it will be regenerated itself.

Return your VS Code panel, move your cursor on the server you want to connect, an icon will be shown on the right. Click it and you will begin connection in the new window. Follow the instruction on the top pop out dialog, then everything should be done.

Enjoy it!

If you want to connect to the server by tools like Putty or Shell…

Remember, you must use the same username as your keys generated, or the server will deny connection. (Error message: Permission denied (publickey))

For example, if we generated the key with username jaylin, and you want to connect to the server by Shell, you must use the command below:

ssh jaylin@ipaddress

After log in as jaylin, if you want to get root permission, you can use

sudo su

If your private keys stored in some specific path, you should use command below:

ssh -i /path/id_rsa jaylin@ipaddress

If you still meet strange problems, try to delete the known_hosts file under C:\Users\username\.ssh.

Posted in Linux

A stop job is running for Snap daemon on Ubuntu [Soulution and Thinking]

Ubuntu has a snap service built in, sometimes it is hard to kill when reboot or shutdown. If the progress cannot be killed easily, system will handle some time (default value is 90s).

So one solution is change the killing time for progress.

First, we need to have Administrator Permission on Linux. Execute the command:

sudo su

Then follow the message on screen to enter your passwords.

Next, we need to edit system files:

“Nano” is a text editor built in Ubuntu, so we can use it. Execute the command:

nano /etc/systemd/system.conf

Don’t be fear because you will find nearly all the text is blue. Why? Because they all comment out with “#” so that no line is effective for the system. What we need to do is uncomment a line and let that line effect.

Use your keyboard arrow keys to move cursor down to find a line called:

#DefaultTimeoutStopSec=90s

Delete the # and change the time to be 10s, like below:

DefaultTimeoutStopSec=10s

You’ll find the color becomes white because it will be effective for the system.

Then press your keyboard with Ctrl+X, you will see the message on the screen to remind you to save changes. We press Y on the keyboard. Then it shows that you can change the file name, but we do nothing, just press Enter key directly.

Use cat command to see the contents of the edited file.

cat /etc/systemd/system.conf

If you are sure there is no error of that file, then you can reboot your system to see the effect, but may be only the second time to reboot will see the effect. You will see the kill time when shutdown will only be 10s. That’s fine.

To reboot quickly, use command:

reboot

But why Snap cannot be stopped as usual? If you’re using Virtual Machine, I think the answer should be there: maybe the snap service in Ubuntu has conflict with Virtual Machine software.

For example, while using VirtualBox, I just use snapshot function restored a snapshot for my Ubuntu server, the conflict will be there. If you just use the console to normally shut down several times, the problem will be gone. To normally shut down, just close the VM window and choose the second option to shut down.

I have changed the system config to 10s once before but I have never seen stuck any more after I normally shut down the machine.

Good luck to you!

Final solution

Ubuntu is based on Debian but worse than it. Although Ubuntu is very popular among developers, it’s still not a good option.

Ubuntu modifies Debian and preinstalls many softwares you needn’t. It will take too much RAM and cause trouble. Snap is one of them and causes too much trouble. Linux Mint, a popular Linux desktop distribution based on Ubuntu, disables Snap by default. Installing packages using apt is good enough.

Also, Snap has bad mechanism. Every software installed via Snap will account for too much space of your disk and update the software automatically. Software installed via Snap would have different file paths, which means it’s hard for you to find out anything, especially following tutorials written by others.

Switching Ubuntu to Debian would be a nice job, especially for server OS. But Debian also supports desktop environment and it works better than Ubuntu. You can choose which desktop environment to use while installing Debian.

However, I found every Debian based Linux distribution would have “processing triggers for man-db” problem. See the detail: https://jaylinwu.wordpress.com/2021/11/23/processing-triggers-for-man-db-takes-too-much-cpu-time-or-disk-io/

But except for man-db problem, Debian is very good in my experience.