使用 hping 时报错的处理

Linux中使用Nmap , hping, ping 提示以下错误时

PHP: [main]	can't	open	raw	socket

Bash: Couldn’t open a raw socket. Error: Permission denied (13)

非root进程调用带有网络原始套接字(raw socket) 的相关命令时,会报错,需要使用getcap 设置 capabilities

(具体参考:https://cloud.tencent.com/developer/article/1539041)

# 以 ping 为例,先 which 查看命令地址
which ping

# 如无返回就是没有设置cap
getcap /usr/bin/ping

# 设置cap
sudo setcap cap_net_raw+ep /usr/bin/ping

# 再次getcap 已有设置值
getcap /usr/bin/ping
#/usr/bin/ping cap_net_raw=ep

setcap 之后问题就解决了。

Linux下date的默认输出格式

在两个debian主机下 使用date命令,显示的格式不一样,分为两种(A/B):

  • A:Sat Sep 14 10:15:03 PM CST 2024
  • B:Sat Sep 14 22:15:15 CST 2024

以晚上十点一刻为例,A 的10:15是12小时制,带有PM, B的22:15是24小时制,没有PM。

所以问题是, 如何设置12小时制 为 24小时制? 继续尝试几种涉及时间设置的命令。

使用 timedatectl查看 : (题外话:该命令在wsl,windows子系统中无效

timedatectl status
 timedatectl status
Local time: Sat 2024-09-14 21:56:01 CST
Universal time: Sat 2024-09-14 13:56:01 UTC
RTC time: Sat 2024-09-14 13:55:53
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
timedatectl status
Local time: Sat 2024-09-14 21:56:07 CST
Universal time: Sat 2024-09-14 13:56:07 UTC
RTC time: n/a
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no

“Local time” , “Universal time”, “Time zone” 时间都是正确,并一致的。时钟同步,NTP服务也都并未使用。RTC time一个有时间,一个为空,应该是虚拟化不同的问题。看来timedatectl的信息并不显示时间是否12/24制式。

locale 查看本地设置:

locale -a
C
C.utf8
en_US.utf8
POSIX
C
C.utf8
POSIX
en_US.utf8

都是 “en_US.utf8″,只是 POSIX顺序不用,也无关。

使用 dpkg-reconfigure tzdata 重新设置时区:

dpkg-reconfigure tzdata

之后再看date,结果证明也与时间12/24制式无关。

使用 date –debug,会显示输出格式:

date --debug
date --debug
date: output format: ‘%a %b %e %r %Z %Y’
Sat Sep 14 10:15:03 PM CST 2024
date --debug
date: output format: '%a %b %e %H:%M:%S %Z %Y'
Sat Sep 14 22:14:50 CST 2024

看到不同了把? date 输出不同时间进制,与设置时间的命令无关。只有输出个格式的不同。那么这个格式是什么决定的?在哪里定义的?

之后看到这篇文章:https://linuxopsys.com/change-default-date-format-in-linux

原来 date 命令的默认日期格式。是根据 locale 中的 LC_TIME 参数,根据参数名,使用关联的设置文件。

例如,运行 locale 命令并查找 LC_TIME 变量。

locale

如图,看到 LC_TIME = “en_US.UTF-8“,这是美国常用的日期格式。

第 2 步:找到与 Locale 关联的文件
locale 文件通常位于 /usr/share/i18n/locales/ 中。您将找到一个名称与您的 LC_TIME locale 设置相对应的文件,如果 LC_TIME 区域设置是 en_US, 对应文件为/usr/share/i18n/locales/en_US


查看 Locale 文件,可以看到其中的 date_fmt 之后的定义 与 date –debug 显示的输出格式一样,

//12小时
"%a %b %e %r %Z %Y"

//24小时
"%a %b %e %H:%M:%S %Z %Y"
~ # date +"%a %b %e %r %Z %Y"
Sun Sep 15 12:16:14 AM CST 2024

~ # date +"%a %b %e %H:%M:%S %Z %Y"
Sun Sep 15 00:17:31 CST 2024

使用 date + “输出格式” 测试, 由此我们发现了问题根源。但是什么,两个“LC_TIME ” 都是 “en_US”,格式会不同呢?答案在 en_US 文件的注释中:

% Appropriate date and time representation for date(1). This is
% different from d_t_fmt for historical reasons and has been different
% since 2000 when date_fmt was added as a GNU extension. At the end
% of 2018 it was adjusted to use 12H time (bug 24046) instead of 24H.

也就是说,一个系统是2018年前安装,或设置生成的 Locale 文件,一个是在2018年之后

结尾

如此,明白了问题根源,就可以通过修改 locale 文件的date_fmt 或 重新设置 LC_TIME 环境变量,重新生成区域设置文件以应用更改。

locale-gen
update-locale

或者 用更简单的方法:

export LC_TIME=POSIX

直接设置 LC_TIME=POSIX,可以快速统一多台,不同本地语言设置的时间格式。

【END】

Apt update : failed to fetch expkeysig abf5bd827bd9bf62 nginx signing key signing-key@nginx.com

apt update ,更新 nginx 时报错。 提示 Nginx 签名无效, 无法获取.

failed to fetch https://nginx.org/packages/mainline/debian/dists/bookworm/inrelease the following signatures were invalid: expkeysig abf5bd827bd9bf62 nginx signing key <signing-key@nginx.com>
解决处理:
  1. 导入 Nginx.org GPG 密钥
curl -fSsL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg > /dev/null

2. 验证密钥是否成功导入

gpg --dry-run --quiet --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

3. 导入 Nginx.org APT 存储库

bash 下执行以下 echo 命令 :

Mainline 存储库 、稳定存储库 二选一!

要导入 Nginx Mainline 存储库,请使用:

echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

或者,对于 Nginx 稳定存储库:

echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list

ICANN终止OpenTLD(Freenom)认证 – 域名转移到Gandi

”人人都熟悉的名字“ — Freenom.com

已经使用了近十年,很好的一家,良心域名注册商,还是被遭到了毒打。Freenom以极低的价格提供域名注册,费用号称成本价,比如.NL 、.EU,还提供TK、CF、GA、GQ、ML 域名的免费注册。最早就是从免费的.TK 域名知道它的。

大约从2023年初开始,已经很久不能注册新域名了。之前看到说是,被Facebook母公司Meta , 在美国加利福尼亚州法院起诉 。被起诉后 Freenom 就由于技术原因新注册申请暂停,当前正在研究解决方案,希望尽快恢复运营。

2024年1月15日我还曾在Freenom续费域名,到2月初,发现域名已经无法续费了。2024/2/12收到了Gandi.net 的支持邮件,告知ICANN终止了OpenTLD(Freenom)的认证- 域名转移到Gandi:

Gandi Support: OpenTLD (Freenom) ICANN accreditation termination – Transfer to Gandi – Recover your domain

Dear registrant,
We are reaching out to you as the owner of the domain name as32.net which was registered with the registrar OpenTLD B․V․, trading as Freenom.
Following the termination of OpenTLD accreditation, ICANN has selected Gandi as the gaining registrar for the gTLD domain names previously managed by OpenTLD. You can find more information about this transfer on the following ICANN page:
https://www.icann.org/resources/pages/bulk-transfers-2017-10-06-en.
If you have not already recovered the management of this domain name at Gandi, please follow the link below. You will be able to import the domain name into your Gandi account if you already have one, or create a Gandi account to be able to manage your domain name.
Import your domain name
We kindly request your attention to the following points:
– Gandi does not provide proxy and privacy services. Consequently, your contact information has been sent to the registry. However in the Whois public database, personal data remain hidden in accordance with ICANN rules. Only the organisation name for legal persons, the state (if available) and the country of the owner contact are published. Email addresses of domain name contacts are anonymized.
– The expiration date of the domain name remains unchanged. You can verify the expiration date via your Gandi account and proceed with renewal if necessary.
Should you have any question, our support team will be delighted to help you:
https://helpdesk.gandi.net.
Thank you for your attention to this matter.
____________________________________________________________

about this transfer on the following ICANN page:
https://www.icann.org/resources/pages/bulk-transfers-2017-10-06-en.

请注意:下表列出了因注册服务机构的认证被 ICANN 终止后所致的批量转移事件。此外,批量转移日期将在终止日期之后。

Terminated RegistrarGaining RegistrarTermination Date
OpenTLD B.V. (IANA #1666)Gandi SAS (IANA #81)25 November 2023
https://www.icann.org/resources/pages/bulk-transfers-2017-10-06-zh

https://www.rayks.com/article/freenom-pending.html

2024 年 2 月 12 日,知名域名注册服务提供商 Freenom 通过其官方网站发布公告,表示 Freenom 及其相关公司已决定退出域名业务,包括注册机构的运营。


Freenom 公司已于 2023 年 3 月 9 日全面停止了新域名的注册业务,但未回收已注册域名且域名到期续费功能也保持开放状态,直到近期宣布“退出域名业务”决定后开始大量收回已注册域名。
Freenom 公司官方宣布内容译文及原文如下:
新闻声明
阿姆斯特丹,2024 年 2 月 12 日。Freenom 今天宣布已解决 Meta Platforms, Inc. Freenom 承认 Meta 在实施其知识产权和保护其用户免受欺诈和滥用方面的合法权益。
Freenom 及其相关公司也已独立决定退出域名业务,包括注册机构的运营。在 Freenom 结束其域名业务的同时,Freenom 将把 Meta 旗下公司视为可信赖的通知方,并将实施阻止列表,以应对未来的网络钓鱼、DNS 滥用和抢注行为。
如需进一步咨询,请联系:
Karin Versteeg
kversteeg@freenom.com
—————————————————原文如下—————————————————
Press Statement
Amsterdam, 12th of February 2024. Freenom today announced it has resolved the lawsuit brought by Meta Platforms, Inc. on confidential monetary and business Terms. Freenom recognizes Meta’s legitimate interest in enforcing its intellectual property rights and protecting its users from fraud and abuse.
Freenom and its related companies have also independently decided to exit the domain name business, including the operation of registries. While Freenom winds down its domain name business, Freenom will treat the Meta family of companies as a trusted notifier and will also implement a block list to address future phishing, DNS abuse, and cybersquatting.
For further inquiries, please contact:
Karin Versteeg
kversteeg@freenom.com
域名注册商 Freenom 宣布退出域名业务 大规模回收免费域名

https://www.rayks.com/article/freenom-pending.html

相关消息:

https://domainnamewire.com/2023/11/10/icann-terminates-opentld-famous-for-its-connection-to-tk-domains/

https://domainnamewire.com/2023/09/21/icann-sends-breach-notice-to-freenoms-accredited-domain-registrar/

https://www.icann.org/uploads/compliance_notice/attachment/1211/hedlund-to-zuurbier-20sep23.pdf

https://zhuanlan.zhihu.com/p/682465154

https://zhuanlan.zhihu.com/p/627211282

https://www.zhihu.com/question/591955285

https://www.zhihu.com/question/644205158

使用 update-alternatives 命令切换软件版本

update-alternatives 的功能,类似于在桌面系统上设置默认打开程序。

# update-alternatives --help
用法:update-alternatives [<选项> ...] <命令>

命令:
  --install <链接> <名称> <路径> <优先级>
    [--slave <链接> <名称> <路径>] ...
                           在系统中加入一组候选项。
  --remove <名称> <路径>   从 <名称> 替换组中去除 <路径> 项。
  --remove-all <名称>      从替换系统中删除 <名称> 替换组。
  --auto <名称>            将 <名称> 的主链接切换到自动模式。
  --display <名称>         显示关于 <名称> 替换组的信息。
  --query <名称>           机器可读版的 --display <名称>.
  --list <名称>            列出 <名称> 替换组中所有的可用候选项。
  --get-selections         列出主要候选项名称以及它们的状态。
  --set-selections         从标准输入中读入候选项的状态。
  --config <名称>          列出 <名称> 替换组中的可选项,并就使用其中
                           哪一个,征询用户的意见。
  --set <名称> <路径>      将 <路径> 设置为 <名称> 的候选项。
  --all                    对所有可选项一一调用 --config 命令。

<链接> 是指向 /etc/alternatives/<名称> 的符号链接。
    (如 /usr/bin/pager)
<名称> 是该链接替换组的主控名。
    (如 pager)
<路径> 是候选项目标文件的位置。
    (如 /usr/bin/less)
<优先级> 是一个整数,在自动模式下,这个数字越高的选项,其优先级也就越高。

选项:
  --altdir <目录>          改变候选项目录。
                             (默认是 /etc/alternatives)。
  --admindir <目录>        设置 statoverride 文件的目录。
                             (默认是 /var/lib/dpkg/alternatives)。
  --instdir <目录>         改变安装目录。
  --root <目录>            改变文件系统根目录。
  --log <文件>             改变日志文件。
  --force                  允许使用候选项链接替换文件。
  --skip-auto              在自动模式中跳过设置正确候选项的提示
                           (只与 --config 有关)
  --quiet                  安静模式,输出尽可能少的信息。
  --verbose                启用详细输出。
  --debug                  调试输出,信息更多。
  --help                   显示本帮助信息。
  --version                显示版本信息。

注册软件: update-alternatives –install

以jdk为例,安装了jdk以后,先要在update-alternatives工具中注册;

# update-alternatives --install /usr/bin/java java /opt/jdk1.8.0_91/bin/java 200
# update-alternatives --install /usr/bin/java java /opt/jdk1.8.0_111/bin/java 300

其中:

  • 第一个参数:--install表示向 update-alternatives 注册服务名。
  • 第二个参数:是注册最终地址,成功后将会把命令在这个固定的目的地址做真实命令的软链,以后管理就是管理这个软链;
  • 第三个参数:服务名,以后管理时以它为关联依据。
  • 第四个参数:被管理的命令绝对路径。
  • 第五个参数:优先级,数字越大优先级越高。

常用示例

显示程序的可替换信息:update-alternatives –display <名称>

 # 显示PHP程序的可替换信息
update-alternatives --display php

php - manual mode
  link best version is /usr/bin/php8.3
  link currently points to /usr/bin/php8.2
  link php is /usr/bin/php
  slave php.1.gz is /usr/share/man/man1/php.1.gz
/usr/bin/php8.2 - priority 82
  slave php.1.gz: /usr/share/man/man1/php8.2.1.gz
/usr/bin/php8.3 - priority 83
  slave php.1.gz: /usr/share/man/man1/php8.3.1.gz

注册添加程序的可替换信息:update-alternatives –install <名称>

# 设置PHP
update-alternatives --install /usr/bin/php php /usr/local/lsws/lsphp74/bin/php 74
update-alternatives --install /usr/bin/php php /usr/local/lsws/lsphp81/bin/php 81
update-alternatives --install /usr/bin/php php /usr/local/lsws/lsphp82/bin/php 82

列出 程序替换组中所有的可用选项:update-alternatives –list <名称>

update-alternatives --list php

/usr/bin/php8.2
/usr/bin/php8.3 

交互式修改:update-alternatives –config <名称> 显示可用选项的列表,选择对应的索引确认。

#设置默认浏览器
update-alternatives --config www-browser 

There is 1 choice for the alternative www-browser (providing /usr/bin/www-browser).

  Selection    Path            Priority   Status
------------------------------------------------------------
* 0            /usr/bin/w3m     25        auto mode
  1            /usr/bin/w3m     25        manual mode

Press <enter> to keep the current choice[*], or type selection number:

#设置默认使用的php版本
update-alternatives --config php

There are 2 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
  0            /usr/bin/php8.3   83        auto mode
* 1            /usr/bin/php8.2   82        manual mode
  2            /usr/bin/php8.3   83        manual mode

Press <enter> to keep the current choice[*], or type selection number: 1

删除替代方案

用 remove 去掉编辑器组中的微替代品:

update-alternatives --remove editor /usr/bin/micro

可以直接使用下面的全部清除:

update-alternatives --remove-all java

解决 apt-get update 从 packages.sury.org 更新 apache2 与 php 时签名无效的错误

apt-get update 显示错误,从 packages.sury.org 更新 apache2 与 php 时签名无效,如下显示:

错误:6 https://packages.sury.org/apache2 bookworm InRelease
  下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

错误:7 https://packages.sury.org/php bookworm InRelease
  下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

------------------------------------------------------------------

Err:6 https://packages.sury.org/apache2 bookworm InRelease
The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

Err:7 https://packages.sury.org/php bookworm InRelease
The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 校验数字签名时出错。此仓库未被更新,所以仍然使用此前的索引文件。GPG 错误:https://packages.sury.org/apache2 bookworm InRelease: 下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 校验数字签名时出错。此仓库未被更新,所以仍然使用此前的索引文件。GPG 错误:https://packages.sury.org/php bookworm InRelease: 下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 无法下载 https://packages.sury.org/apache2/dists/bookworm/InRelease 下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 无法下载 https://packages.sury.org/php/dists/bookworm/InRelease 下列签名无效: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: 部分索引文件下载失败。如果忽略它们,那将转而使用旧的索引文件。

————————————————————————————————–

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/apache2 bookworm InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php bookworm InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: Failed to fetch https://packages.sury.org/apache2/dists/bookworm/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: Failed to fetch https://packages.sury.org/php/dists/bookworm/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org

W: Some index files failed to download. They have been ignored, or old ones used instead.

解决办法:

参考 packages.sury.org 站点 README.txt 文件的脚本。

apache2 https://packages.sury.org/apache2/README.txt
php https://packages.sury.org/php/README.txt

apache2

apt-get update
apt-get -y install lsb-release ca-certificates curl
curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
dpkg -i /tmp/debsuryorg-archive-keyring.deb
sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-apache2.gpg] https://packages.sury.org/apache2/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/apache2.list'
apt-get update

php

apt-get update
apt-get -y install lsb-release ca-certificates curl
curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
dpkg -i /tmp/debsuryorg-archive-keyring.deb
sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
apt-get update

【END】

使用 HttpRepl 浏览、测试 Web API

The HTTP Read-Eval-Print Loop (REPL) 

  • 一种轻量级跨平台命令行工具,在所有支持的 .NET Core 的位置都可得到支持。
  • 用于发出 HTTP 请求以测试 ASP.NET Core Web API(和非 ASP.NET Core web API)并查看其结果。
  • 可以在任何环境下测试托管的 web API,包括 localhost 和 Azure 应用服务。

安装:dotnet tool install -g Microsoft.dotnet-httprepl

(视频)使用 HttpRepl 浏览 Web API:

https://learn.microsoft.com/zh-cn/shows/beginners-series-to-web-apis/exploring-web-apis-with-the-httprepl-16-of-18–beginners-series-to-web-apis

使用 HttpRepl 测试 Web API

https://learn.microsoft.com/zh-cn/aspnet/core/web-api/http-repl/?view=aspnetcore-8.0&tabs=windows

HttpRepl:用于与 RESTful HTTP 服务交互的命令行工具

https://devblogs.microsoft.com/dotnet/httprepl-a-command-line-tool-for-interacting-with-restful-http-services/#configure-visual-studio-for-windows-to-launch-httprepl-on-f5

HttpRepl GitHub 存储库https://github.com/dotnet/HttpRepl

使用Certbot生成Let’s Encrypt证书,为OpenLiteSpeed 配置 SSL

使用 Let’s Encrypt 快速安装 SSL

手动certbot ,单独注册证书,最快获取Let’s Encrypt SSL证书的方式。。。

设置,先安装certbot

sudo apt-get update
sudo apt-get install certbot -y

以非交互式申请证书:

如要申请证书:example.com

certbot certonly --non-interactive --agree-tos -m demo@gmail.com --webroot -w /var/www/html -d example.com

要同时申请证书,并且:example.comwww.example.com

certbot certonly --non-interactive --agree-tos -m demo@gmail.com --webroot -w /var/www/html -d example.com -d www.example.com

OpenLiteSpeed 下的 SSL设置

  • 1. 如果我们只有一个证书,我们可以在侦听器级别设置它。

导航到 OpenLiteSpeed > Web 控制台> 侦听器> SSL > SSL 私钥和证书
设置以下值:

  • 私钥文件/etc/letsencrypt/live/YOUR_DOMAIN/privkey.pem
  • 证书文件/etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem

单击“保存”,然后执行“平滑重启”。

  • 2. 配置多个 SSL

虚拟主机中的SSL证书将覆盖侦听器,因此我们只需将证书添加到每个域的虚拟主机即可。

导航到 OpenLiteSpeed > Web 控制台>虚拟主机>您的虚拟主机> SSL > SSL 私钥和证书
设置以下值:

  • 私钥文件/etc/letsencrypt/live/YOUR_DOMAIN/privkey.pem
  • 证书文件/etc/letsencrypt/live/YOUR_DOMAIN/fullchain.pem

单击“保存”,然后执行平滑重启”。

screen后台运行|恢复会话|断开当前会话

screen 控制 ssh 远程会话命令不中断。避免终端窗口关闭/网络断开 后的 进程会话中断。

新建screen

screen -S your_screen_name

Ctrl + a, d :断开当前 screen 会话,但保持会话在后台运行。 Ctrl + a, k :关闭当前窗口或会话。

进入screen

screen -r your_screen_name

Ctrl+D # 在当前screen下,输入Ctrl+D,删除该screen
Ctrl+A,Ctrl+D # 在当前screen下,输入先后Ctrl+A,Ctrl+D,退出该screen

显示screen list

​​​​​​​screen -ls

连接状态为【Attached】的screen

解决恢复会话时出现 There is no screen to be resumed matching 的错误

screen -D -r your_screen_name # 解释:-D -r 先踢掉前一用户,再登陆

判断当前是否在screen中断下,Ubuntu系统,可以这样:

sudo vim /etc/screenrc

文件末尾追加一行即可允许设置screen标题

caption always "%{.bW}%-w%{.rW}%n %t%{-}%+w %=%H %Y/%m/%d "

删除指定screen, your_screen_name为待删除的screen name

​​​​​​​screen -S your_screen_name -X quit

使用service –status-all 或 systemctl status 查询服务状态时卡顿

问题:

在一个运行多年的 debian 系统中,使用 service --status-all 检查服务列表
输出到项目 "[ + ]  cron" 时,会卡顿很久,才继续显示其他服务名。

起初不知道为什么卡顿,今天看到一文,他在 systemctl status 某服务名 时卡顿很久,后来发现这个问题和systemd-journald有关。我感觉这个问题也有可能一样,老系统运行多年,记录的服务信息过多。决定也尝试清理一下journald。

单独查看service --status-all 中卡顿的 cron

systemctl status cron

果真,翻页几千行,才发现看了不到一个月的记录,太多了

cron 是定时执行任务的服务。各种计划任务的执行都会产生大量的服务启动日志。

可以看出 systemctl 输出服务启动时的相关信息。都是从systemd-journald中读取的。

进入文件夹 /var/log/journal,里面有一个长文件名的文件夹:f25c9fe2e9554b54950734c0b92298e0,里面是用户的 system.journal 文件,还有user-1000.journal。

ls -lhm --full-time /var/log/journal/f25c9fe2e9554b54950734c0b92298e0/

查看这个文件夹下文件大小,21,001,486,336 bytes 有19.5 GiB。

下面清理 journal 文件

先停止 systemd-journald 服务

systemctl stop systemd-journald

Warning: Stopping systemd-journald.service, but it can still be activated by:
  systemd-journald-dev-log.socket
  systemd-journald.socket
  systemd-journald-audit.socket

提示警告,为了保险,把这几个都停止掉:
systemctl stop systemd-journald-dev-log.socket
systemctl stop systemd-journald.socket
systemctl stop systemd-journald-audit.socket

然后可以删除 journal 文件(我直接全部删除了,重要的生产服务器不建议这样)
 

最后是要限制systemd-journald日志的大小,避免以后出现这个问题。

编辑文件: /etc/systemd/journald.conf

修改以下两个配置参数:

SystemMaxUse=100M
RuntimeMaxUse=100M

限制全部日志文件加在一起最多可以占用多少空间,相对的问题是,以后的日志记录总量也变少了。

最后重启 systemd-journald

systemctl restart systemd-journald

再次使用 service –status-all 或 systemctl status 查询服务状态时,就不再出现卡顿了。

systemctl daemon-reload #重新加载服务配置文件

[end]