:Troubleshoot remote connection failures or "Too many open files" errors from nofile parameter adjustments

With instance access

1. Log on to the ECS instance as the root user.

   1. Go to the ECS console - Instances page. In the upper-left corner, select the resource group and region where the instance is located.

   2. Go to the details page of the target instance. Click Connect and select Workbench. Follow the on-screen prompts to log on as the root user and open the terminal.

2. Modify the configuration file.

   Edit the /etc/security/limits.conf file. Change the values of the hard nofile and soft nofile parameters to the default value 65535. Then, save the file and exit.

   * soft nofile 65535
   * hard nofile 65535
   root soft nofile 65535
   root hard nofile 65535

   • An asterisk (*) applies to all normal users, and root applies to the root user.

   • hard nofile: The hard limit on the number of open files. This value cannot exceed the limit set by the fs.nr_open kernel parameter. Otherwise, you may not be able to log on to the instance.

   • soft nofile: The current limit on the number of open files. This value cannot exceed the hard nofile limit. Otherwise, this configuration is ignored.

     If the value of soft nofile is greater than the value of hard nofile, the effective nofile value is the value of the hard nofile parameter.

3. Apply the new configuration.

   1. Log out of and log on to the ECS instance again as the target user to apply the changes.

   2. Run the sudo ulimit -n command. If the output is 65535, the nofile limit is updated.

4. Restart the related applications and verify that they function as normal.

Without instance access

If no historical snapshot is available, prepare a healthy Linux instance that is in the same zone as the problematic instance. You can then change the nofile parameter by attaching the system disk of the problematic instance to the healthy instance.

1. Detach the system disk.

   Make sure that the problematic instance is in the Stopped state and perform the following steps:

   1. To prevent accidental data loss, create a manual snapshot of the system disk.

   2. Go to the ECS console - Instances page. In the upper-left corner, select the resource group and region where the instance is located.

   3. Click the ID of the problematic instance to go to the Instance Details page. Then, click the Block Storage tab.

   4. In the System Disk section, find the Actions column and choose > Detach.

   5. In the Detach Disk dialog box, confirm the information and click OK. When the instance status changes to No System Disk, the disk is successfully detached.

2. Attach the disk as a data disk to a healthy instance.

   Make sure that the healthy instance is in the Running state and perform the following steps:

   1. Attach the system disk of the problematic instance to the healthy instance.

      1. Click the ID of the healthy instance to go to its details page.

      2. Click the Block Storage tab and then click Attach Disk.

      3. On the Attach to Instance page, select the detached system disk in the Disk section and click Next.

      4. On the Partition Disk and Create and Mount File Systems page, select Configure Later to complete the attachment.

   2. Click Connect and select Workbench. Follow the on-screen prompts to log on as the root user and open the terminal.

   3. Mount the file system.

      1. Identify the partition name of the problematic disk.

         lsblk -f

         vda                                                      
         ├─vda1                                                   
         ├─vda2 vfat         7938-FA03                            /boot/efi
         └─vda3 ext4   root  33b46ac5-7482-4aa5-8de0-60ab4c3a4c78 /
         vdb                                                      
         ├─vdb1                                                   
         ├─vdb2 vfat         7938-FA03                            
         └─vdb3 ext4   root  33b46ac5-7482-4aa5-8de0-60ab4c3a4c78                                  

         In this example, the root partition of the problematic disk vdb is vdb3. This is the partition that you need to mount. The partitions are described as follows:

         • vdb1/vdb2: These partitions contain system boot files and can be ignored.

         • vdb3: This is the root partition that contains operating system files and user data. It must be mounted.

      2. Create a directory and mount the file system.

         mkdir <mount_point> && sudo mount /dev/<partition_name> <mount_point>

         Parameter	Description
         <partition_name>	The name of the root partition of the problematic disk that you identified in the preceding step.
         <mount_point>	A custom <mount point> must be an empty path that starts with / and must be unique. Important If you mount a file system on a non-empty directory, the original files in that directory are hidden and become inaccessible. Proceed with caution.

         For example, to mount the target partition vdb3 to the newly created /test directory, run the mkdir /test && sudo mount /dev/vdb3 /test command.

      3. Check the mount result.

         Run the lsblk command. If the target partition has a mount point in the MOUNTPOINT column, the file system is successfully mounted.

3. Modify the configuration file.

   Edit the <mount_point>/etc/security/limits.conf file. Change the values of the hard nofile and soft nofile parameters to the default value 65535. Then, save the file and exit.

   * soft nofile 65535
   * hard nofile 65535
   root soft nofile 65535
   root hard nofile 65535

   • An asterisk (*) applies to all users, and root applies to the root user.

   • hard nofile: Specifies the hard limit on the number of open files. This value cannot exceed the value of the kernel parameter <mount point>/proc/sys/fs/nr_open. Otherwise, you may be unable to log in to the instance.

   • soft nofile: The current limit on the number of open files. This value cannot exceed the hard nofile limit. Otherwise, this configuration is ignored.

     If the value of soft nofile is greater than the value of hard nofile, the effective nofile value is the value of the hard nofile parameter.

4. Attach the disk back to the original ECS instance as a system disk.

   1. Unmount the file system.

      Replace <mount_point> with the actual mount point.

      umount <mount_point>

      For example, run the umount /test command.

   2. Detach the repaired system disk.

      1. Return to the ECS console and go to the Block Storage tab of the healthy instance details page.

      2. In the Actions column for the repaired system disk, click Detach.

      3. In the Detach Disk dialog box, click OK.

   3. Attach the repaired system disk back to the original instance.

      1. Go to the Block Storage tab of the problematic instance details page and click Attach Disk.

      2. On the Attach to Instance page, select the repaired system disk from the Disk list. Configure the Logon Credentials and click Next.

      3. On the Partition Disk and Create and Mount File Systems page, select Configure Later to complete the attachment.

   4. Start the ECS instance.

5. Log on to the original ECS instance and verify that it functions as normal.