分类 技术 下的文章

使用 strace 跟踪用户进程和 Linux 内核之间的交互。

系统调用 system call 是程序从内核请求服务的一种编程方式,而 strace 是一个功能强大的工具,可让你跟踪用户进程与 Linux 内核之间的交互。

要了解操作系统的工作原理,首先需要了解系统调用的工作原理。操作系统的主要功能之一是为用户程序提供抽象机制。

操作系统可以大致分为两种模式:

  • 内核模式:操作系统内核使用的一种强大的特权模式
  • 用户模式:大多数用户应用程序运行的地方 用户大多使用命令行实用程序和图形用户界面(GUI)来执行日常任务。系统调用在后台静默运行,与内核交互以完成工作。

系统调用与函数调用非常相似,这意味着它们都接受并处理参数然后返回值。唯一的区别是系统调用进入内核,而函数调用不进入。从用户空间切换到内核空间是使用特殊的 trap) 机制完成的。

通过使用系统库(在 Linux 系统上又称为 glibc),大部分系统调用对用户隐藏了。尽管系统调用本质上是通用的,但是发出系统调用的机制在很大程度上取决于机器(架构)。

本文通过使用一些常规命令并使用 strace 分析每个命令进行的系统调用来探索一些实际示例。这些示例使用 Red Hat Enterprise Linux,但是这些命令运行在其他 Linux 发行版上应该也是相同的:

[root@sandbox ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.7 (Maipo)
[root@sandbox ~]#
[root@sandbox ~]# uname -r
3.10.0-1062.el7.x86_64
[root@sandbox ~]#

首先,确保在系统上安装了必需的工具。你可以使用下面的 rpm 命令来验证是否安装了 strace。如果安装了,则可以使用 -V 选项检查 strace 实用程序的版本号:

[root@sandbox ~]# rpm -qa | grep -i strace
strace-4.12-9.el7.x86_64
[root@sandbox ~]#
[root@sandbox ~]# strace -V
strace -- version 4.12
[root@sandbox ~]#

如果没有安装,运行命令安装:

yum install strace

出于本示例的目的,在 /tmp 中创建一个测试目录,并使用 touch 命令创建两个文件:

[root@sandbox ~]# cd /tmp/
[root@sandbox tmp]#
[root@sandbox tmp]# mkdir testdir
[root@sandbox tmp]#
[root@sandbox tmp]# touch testdir/file1
[root@sandbox tmp]# touch testdir/file2
[root@sandbox tmp]#

(我使用 /tmp 目录是因为每个人都可以访问它,但是你可以根据需要选择另一个目录。)

testdir 目录下使用 ls 命令验证该文件已经创建:

[root@sandbox tmp]# ls testdir/
file1  file2
[root@sandbox tmp]#

你可能每天都在使用 ls 命令,而没有意识到系统调用在其下面发挥的作用。抽象地来说,该命令的工作方式如下:

命令行工具 -> 从系统库(glibc)调用函数 -> 调用系统调用

ls 命令内部从 Linux 上的系统库(即 glibc)调用函数。这些库去调用完成大部分工作的系统调用。

如果你想知道从 glibc 库中调用了哪些函数,请使用 ltrace 命令,然后跟上常规的 ls testdir/命令:

ltrace ls testdir/

如果没有安装 ltrace,键入如下命令安装:

yum install ltrace

大量的输出会被堆到屏幕上;不必担心,只需继续就行。ltrace 命令输出中与该示例有关的一些重要库函数包括:

opendir("testdir/")                                  = { 3 }
readdir({ 3 })                                       = { 101879119, "." }
readdir({ 3 })                                       = { 134, ".." }
readdir({ 3 })                                       = { 101879120, "file1" }
strlen("file1")                                      = 5
memcpy(0x1665be0, "file1\0", 6)                      = 0x1665be0
readdir({ 3 })                                       = { 101879122, "file2" }
strlen("file2")                                      = 5
memcpy(0x166dcb0, "file2\0", 6)                      = 0x166dcb0
readdir({ 3 })                                       = nil
closedir({ 3 })                                         

通过查看上面的输出,你或许可以了解正在发生的事情。opendir 库函数打开一个名为 testdir 的目录,然后调用 readdir 函数,该函数读取目录的内容。最后,有一个对 closedir 函数的调用,该函数将关闭先前打开的目录。现在请先忽略其他 strlenmemcpy 功能。

你可以看到正在调用哪些库函数,但是本文将重点介绍由系统库函数调用的系统调用。

与上述类似,要了解调用了哪些系统调用,只需将 strace 放在 ls testdir 命令之前,如下所示。 再次,一堆乱码丢到了你的屏幕上,你可以按照以下步骤进行操作:

[root@sandbox tmp]# strace ls testdir/
execve("/usr/bin/ls", ["ls", "testdir/"], [/* 40 vars */]) = 0
brk(NULL)                               = 0x1f12000
<<< truncated strace output >>>
write(1, "file1  file2\n", 13file1  file2
)          = 13
close(1)                                = 0
munmap(0x7fd002c8d000, 4096)            = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++
[root@sandbox tmp]#

运行 strace 命令后屏幕上的输出就是运行 ls 命令的系统调用。每个系统调用都为操作系统提供了特定的用途,可以将它们大致分为以下几个部分:

  • 进程管理系统调用
  • 文件管理系统调用
  • 目录和文件系统管理系统调用
  • 其他系统调用

分析显示到屏幕上的信息的一种更简单的方法是使用 strace 方便的 -o 标志将输出记录到文件中。在 -o 标志后添加一个合适的文件名,然后再次运行命令:

[root@sandbox tmp]# strace -o trace.log ls testdir/
file1  file2
[root@sandbox tmp]#

这次,没有任何输出干扰屏幕显示,ls 命令如预期般工作,显示了文件名并将所有输出记录到文件 trace.log 中。仅仅是一个简单的 ls 命令,该文件就有近 100 行内容:

[root@sandbox tmp]# ls -l trace.log
-rw-r--r--. 1 root root 7809 Oct 12 13:52 trace.log
[root@sandbox tmp]#
[root@sandbox tmp]# wc -l trace.log
114 trace.log
[root@sandbox tmp]#

让我们看一下这个示例的 trace.log 文件的第一行:

execve("/usr/bin/ls", ["ls", "testdir/"], [/* 40 vars */]) = 0
  • 该行的第一个单词 execve 是正在执行的系统调用的名称。
  • 括号内的文本是提供给该系统调用的参数。
  • 符号 = 后的数字(在这种情况下为 0)是 execve 系统调用的返回值。

现在的输出似乎还不太吓人,对吧。你可以应用相同的逻辑来理解其他行。

现在,将关注点集中在你调用的单个命令上,即 ls testdir。你知道命令 ls 使用的目录名称,那么为什么不在 trace.log 文件中使用 grep 查找 testdir 并查看得到的结果呢?让我们详细查看一下结果的每一行:

[root@sandbox tmp]# grep testdir trace.log
execve("/usr/bin/ls", ["ls", "testdir/"], [/* 40 vars */]) = 0
stat("testdir/", {st_mode=S_IFDIR|0755, st_size=32, ...}) = 0
openat(AT_FDCWD, "testdir/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[root@sandbox tmp]#

回顾一下上面对 execve 的分析,你能说一下这个系统调用的作用吗?

execve("/usr/bin/ls", ["ls", "testdir/"], [/* 40 vars */]) = 0

你无需记住所有系统调用或它们所做的事情,因为你可以在需要时参考文档。手册页可以解救你!在运行 man 命令之前,请确保已安装以下软件包:

[root@sandbox tmp]# rpm -qa | grep -i man-pages
man-pages-3.53-5.el7.noarch
[root@sandbox tmp]#

请记住,你需要在 man 命令和系统调用名称之间添加 2。如果使用 man man 阅读 man 命令的手册页,你会看到第 2 节是为系统调用保留的。同样,如果你需要有关库函数的信息,则需要在 man 和库函数名称之间添加一个 3

以下是手册的章节编号及其包含的页面类型:

  • 1:可执行的程序或 shell 命令
  • 2:系统调用(由内核提供的函数)
  • 3:库调用(在程序的库内的函数)
  • 4:特殊文件(通常出现在 /dev

使用系统调用名称运行以下 man 命令以查看该系统调用的文档:

man 2 execve

按照 execve 手册页,这将执行在参数中传递的程序(在本例中为 ls)。可以为 ls 提供其他参数,例如本例中的 testdir。因此,此系统调用仅以 testdir 作为参数运行 ls

execve - execute program

DESCRIPTION
       execve()  executes  the  program  pointed to by filename

下一个系统调用,名为 stat,它使用 testdir 参数:

stat("testdir/", {st_mode=S_IFDIR|0755, st_size=32, ...}) = 0

使用 man 2 stat 访问该文档。stat 是获取文件状态的系统调用,请记住,Linux 中的一切都是文件,包括目录。

接下来,openat 系统调用将打开 testdir。密切注意返回的 3。这是一个文件描述符,将在以后的系统调用中使用:

openat(AT_FDCWD, "testdir/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3

到现在为止一切都挺好。现在,打开 trace.log 文件,并转到 openat 系统调用之后的行。你会看到 getdents 系统调用被调用,该调用完成了执行 ls testdir 命令所需的大部分操作。现在,从 trace.log 文件中用 grep 获取 getdents

[root@sandbox tmp]# grep getdents trace.log
getdents(3, /* 4 entries */, 32768)     = 112
getdents(3, /* 0 entries */, 32768)     = 0
[root@sandbox tmp]#

getdents 的手册页将其描述为 “获取目录项”,这就是你要执行的操作。注意,getdents 的参数是 3,这是来自上面 openat 系统调用的文件描述符。

现在有了目录列表,你需要一种在终端中显示它的方法。因此,在日志中用 grep 搜索另一个用于写入终端的系统调用 write

[root@sandbox tmp]# grep write trace.log
write(1, "file1  file2\n", 13)          = 13
[root@sandbox tmp]#

在这些参数中,你可以看到将要显示的文件名:file1file2。关于第一个参数(1),请记住在 Linux 中,当运行任何进程时,默认情况下会为其打开三个文件描述符。以下是默认的文件描述符:

  • 0:标准输入
  • 1:标准输出
  • 2:标准错误

因此,write 系统调用将在标准显示(就是这个终端,由 1 所标识的)上显示 file1file2

现在你知道哪个系统调用完成了 ls testdir/ 命令的大部分工作。但是在 trace.log 文件中其它的 100 多个系统调用呢?操作系统必须做很多内务处理才能运行一个进程,因此,你在该日志文件中看到的很多内容都是进程初始化和清理。阅读整个 trace.log 文件,并尝试了解 ls 命令是怎么工作起来的。

既然你知道了如何分析给定命令的系统调用,那么就可以将该知识用于其他命令来了解正在执行哪些系统调用。strace 提供了许多有用的命令行标志,使你更容易使用,下面将对其中一些进行描述。

默认情况下,strace 并不包含所有系统调用信息。但是,它有一个方便的 -v 冗余选项,可以在每个系统调用中提供附加信息:

strace -v ls testdir

在运行 strace 命令时始终使用 -f 选项是一种好的作法。它允许 strace 对当前正在跟踪的进程创建的任何子进程进行跟踪:

strace -f ls testdir

假设你只需要系统调用的名称、运行的次数以及每个系统调用花费的时间百分比。你可以使用 -c 标志来获取这些统计信息:

strace -c ls testdir/

假设你想专注于特定的系统调用,例如专注于 open 系统调用,而忽略其余部分。你可以使用-e 标志跟上系统调用的名称:

[root@sandbox tmp]# strace -e open ls testdir
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libacl.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libattr.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
file1  file2
+++ exited with 0 +++
[root@sandbox tmp]#

如果你想关注多个系统调用怎么办?不用担心,你同样可以使用 -e 命令行标志,并用逗号分隔开两个系统调用的名称。例如,要查看 writegetdents 系统调用:

[root@sandbox tmp]# strace -e write,getdents ls testdir
getdents(3, /* 4 entries */, 32768)     = 112
getdents(3, /* 0 entries */, 32768)     = 0
write(1, "file1  file2\n", 13file1  file2
)          = 13
+++ exited with 0 +++
[root@sandbox tmp]#

到目前为止,这些示例是明确地运行的命令进行了跟踪。但是,要跟踪已经运行并正在执行的命令又怎么办呢?例如,如果要跟踪用来长时间运行进程的守护程序,该怎么办?为此,strace 提供了一个特殊的 -p 标志,你可以向其提供进程 ID。

我们的示例不在守护程序上运行 strace,而是以 cat 命令为例,如果你将文件名作为参数,通常 cat 会显示文件的内容。如果没有给出参数,cat 命令会在终端上等待用户输入文本。输入文本后,它将重复给定的文本,直到用户按下 Ctrl + C 退出为止。

从一个终端运行 cat 命令;它会向你显示一个提示,并等待在那里(记住 cat 仍在运行且尚未退出):

[root@sandbox tmp]# cat

在另一个终端上,使用 ps 命令找到进程标识符(PID):

[root@sandbox ~]# ps -ef | grep cat
root      22443  20164  0 14:19 pts/0    00:00:00 cat
root      22482  20300  0 14:20 pts/1    00:00:00 grep --color=auto cat
[root@sandbox ~]#

现在,使用 -p 标志和 PID(在上面使用 ps 找到)对运行中的进程运行 strace。运行 strace 之后,其输出说明了所接驳的进程的内容及其 PID。现在,strace 正在跟踪 cat 命令进行的系统调用。看到的第一个系统调用是 read,它正在等待文件描述符 0(标准输入,这是运行 cat 命令的终端)的输入:

[root@sandbox ~]# strace -p 22443
strace: Process 22443 attached
read(0,

现在,返回到你运行 cat 命令的终端,并输入一些文本。我出于演示目的输入了 x0x0。注意 cat 是如何简单地重复我输入的内容的。因此,x0x0 出现了两次。我输入了第一个,第二个是 cat 命令重复的输出:

[root@sandbox tmp]# cat
x0x0
x0x0

返回到将 strace 接驳到 cat 进程的终端。现在你会看到两个额外的系统调用:较早的 read 系统调用,现在在终端中读取 x0x0,另一个为 write,它将 x0x0 写回到终端,然后是再一个新的 read,正在等待从终端读取。请注意,标准输入(0)和标准输出(1)都在同一终端中:

[root@sandbox ~]# strace -p 22443
strace: Process 22443 attached
read(0, "x0x0\n", 65536)                = 5
write(1, "x0x0\n", 5)                   = 5
read(0,

想象一下,对守护进程运行 strace 以查看其在后台执行的所有操作时这有多大帮助。按下 Ctrl + C 杀死 cat 命令;由于该进程不再运行,因此这也会终止你的 strace 会话。

如果要查看所有的系统调用的时间戳,只需将 -t 选项与 strace 一起使用:

[root@sandbox ~]#strace -t ls testdir/

14:24:47 execve("/usr/bin/ls", ["ls", "testdir/"], [/* 40 vars */]) = 0
14:24:47 brk(NULL)                      = 0x1f07000
14:24:47 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2530bc8000
14:24:47 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
14:24:47 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3

如果你想知道两次系统调用之间所花费的时间怎么办?strace 有一个方便的 -r 命令,该命令显示执行每个系统调用所花费的时间。非常有用,不是吗?

[root@sandbox ~]#strace -r ls testdir/

0.000000 execve("/usr/bin/ls", ["ls", "testdir/"], [/* 40 vars */]) = 0
0.000368 brk(NULL)                 = 0x1966000
0.000073 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb6b1155000
0.000047 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
0.000119 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3

总结

strace 实用程序非常有助于理解 Linux 上的系统调用。要了解它的其它命令行标志,请参考手册页和在线文档。


via: https://opensource.com/article/19/10/strace

作者:Gaurav Kamathe 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

让我们开始使用它。

awk 是用于 Unix 和类 Unix 系统的强大文本解析工具,但是由于它有可编程函数,因此你可以用它来执行常规解析任务,因此它也被视为一种编程语言。你可能不会使用 awk 开发下一个 GUI 应用,并且它可能不会代替你的默认脚本语言,但是它是用于特定任务的强大程序。

这些任务或许是惊人的多样化。了解 awk 可以解决你的哪些问题的最好方法是学习 awk。你会惊讶于 awk 如何帮助你完成更多工作,却花费更少的精力。

awk 的基本语法是:

awk [options] 'pattern {action}' file

首先,创建此示例文件并将其保存为 colours.txt

name       color  amount
apple      red    4
banana     yellow 6
strawberry red    3
grape      purple 10
apple      green  8
plum       purple 2
kiwi       brown  4
potato     brown  9
pineapple  yellow 5

数据被一个或多个空格分隔为列。以某种方式组织要分析的数据是很常见的。它不一定总是由空格分隔的列,甚至可以不是逗号或分号,但尤其是在日志文件或数据转储中,通常有一个可预测的格式。你可以使用数据格式来帮助 awk 提取和处理你关注的数据。

打印列

awk 中,print 函数显示你指定的内容。你可以使用许多预定义的变量,但是最常见的是文本文件中以整数命名的列。试试看:

$ awk '{print $2;}' colours.txt
color
red
yellow
red
purple
green
purple
brown
brown
yellow

在这里,awk 显示第二列,用 $2 表示。这是相对直观的,因此你可能会猜测 print $1 显示第一列,而 print $3 显示第三列,依此类推。

要显示全部列,请使用 $0

美元符号($)后的数字是表达式,因此 $2$(1+1) 是同一意思。

有条件地选择列

你使用的示例文件非常结构化。它有一行充当标题,并且各列直接相互关联。通过定义条件,你可以限定 awk 在找到此数据时返回的内容。例如,要查看第二列中与 yellow 匹配的项并打印第一列的内容:

awk '$2=="yellow"{print $1}' file1.txt
banana
pineapple

正则表达式也可以工作。此表达式近似匹配 $2 中以 p 开头跟上任意数量(一个或多个)字符后继续跟上 p 的值:

$ awk '$2 ~ /p.+p/ {print $0}' colours.txt
grape   purple  10
plum    purple  2

数字能被 awk 自然解释。例如,要打印第三列包含大于 5 的整数的行:

awk '$3>5 {print $1, $2}' colours.txt
name    color
banana  yellow
grape   purple
apple   green
potato  brown

字段分隔符

默认情况下,awk 使用空格作为字段分隔符。但是,并非所有文本文件都使用空格来定义字段。例如,用以下内容创建一个名为 colours.csv 的文件:

name,color,amount
apple,red,4
banana,yellow,6
strawberry,red,3
grape,purple,10
apple,green,8
plum,purple,2
kiwi,brown,4
potato,brown,9
pineapple,yellow,5

只要你指定将哪个字符用作命令中的字段分隔符,awk 就能以完全相同的方式处理数据。使用 --field-separator(或简称为 -F)选项来定义分隔符:

$ awk -F"," '$2=="yellow" {print $1}' file1.csv
banana
pineapple

保存输出

使用输出重定向,你可以将结果写入文件。例如:

$ awk -F, '$3>5 {print $1, $2} colours.csv > output.txt

这将创建一个包含 awk 查询内容的文件。

你还可以将文件拆分为按列数据分组的多个文件。例如,如果要根据每行显示的颜色将 colours.txt 拆分为多个文件,你可以在 awk 中包含重定向语句来重定向每条查询

$ awk '{print > $2".txt"}' colours.txt

这将生成名为 yellow.txtred.txt 等文件。

在下一篇文章中,你将了解有关字段,记录和一些强大的 awk 变量的更多信息。

本文改编自社区技术播客 Hacker Public Radio


via: https://opensource.com/article/19/10/intro-awk

作者:Seth Kenlon 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

很多次,你可能遇见过系统消耗了过多的内存。如果是这种情况,那么最好的办法是识别出 Linux 机器上消耗过多内存的进程。我相信,你可能已经运行了下文中的命令以进行检查。如果没有,那你尝试过哪些其他的命令?我希望你可以在评论中更新这篇文章,它可能会帮助其他用户。

使用 top 命令ps 命令 可以轻松的识别这种情况。我过去经常同时使用这两个命令,两个命令得到的结果是相同的。所以我建议你从中选择一个喜欢的使用就可以。

1) 如何使用 ps 命令在 Linux 中查找内存消耗最大的进程

ps 命令用于报告当前进程的快照。ps 命令的意思是“进程状态”。这是一个标准的 Linux 应用程序,用于查找有关在 Linux 系统上运行进程的信息。

它用于列出当前正在运行的进程及其进程 ID(PID)、进程所有者名称、进程优先级(PR)以及正在运行的命令的绝对路径等。

下面的 ps 命令格式为你提供有关内存消耗最大进程的更多信息。

# ps aux --sort -rss | head

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1064  3.2  5.4 886076 209988 ?       Ssl  Oct25  62:40 /usr/sbin/mysqld
varnish  23396  0.0  2.9 286492 115616 ?       SLl  Oct25   0:42 /usr/sbin/varnishd -P /var/run/varnish.pid -f /etc/varnish/default.vcl -a :82 -T 127.0.0.1:6082 -S /etc/varnish/secret -s malloc,256M
named     1105  0.0  2.7 311712 108204 ?       Ssl  Oct25   0:16 /usr/sbin/named -u named -c /etc/named.conf
nobody   23377  0.2  2.3 153096 89432 ?        S    Oct25   4:35 nginx: worker process
nobody   23376  0.1  2.1 147096 83316 ?        S    Oct25   2:18 nginx: worker process
root     23375  0.0  1.7 131028 66764 ?        Ss   Oct25   0:01 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nobody   23378  0.0  1.6 130988 64592 ?        S    Oct25   0:00 nginx: cache manager process
root      1135  0.0  0.9  86708 37572 ?        S    05:37   0:20 cwpsrv: worker process
root      1133  0.0  0.9  86708 37544 ?        S    05:37   0:05 cwpsrv: worker process

使用以下 ps 命令格式可在输出中仅展示有关内存消耗过程的特定信息。

# ps -eo pid,ppid,%mem,%cpu,cmd --sort=-%mem | head

  PID  PPID %MEM %CPU CMD
 1064     1  5.4  3.2 /usr/sbin/mysqld
23396 23386  2.9  0.0 /usr/sbin/varnishd -P /var/run/varnish.pid -f /etc/varnish/default.vcl -a :82 -T 127.0.0.1:6082 -S /etc/varnish/secret -s malloc,256M
 1105     1  2.7  0.0 /usr/sbin/named -u named -c /etc/named.conf
23377 23375  2.3  0.2 nginx: worker process
23376 23375  2.1  0.1 nginx: worker process
 3625   977  1.9  0.0 /usr/local/bin/php-cgi /home/daygeekc/public_html/index.php
23375     1  1.7  0.0 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
23378 23375  1.6  0.0 nginx: cache manager process
 1135  3034  0.9  0.0 cwpsrv: worker process

如果你只想查看命令名称而不是命令的绝对路径,请使用下面的 ps 命令格式。

# ps -eo pid,ppid,%mem,%cpu,comm --sort=-%mem | head

  PID  PPID %MEM %CPU COMMAND
 1064     1  5.4  3.2 mysqld
23396 23386  2.9  0.0 cache-main
 1105     1  2.7  0.0 named
23377 23375  2.3  0.2 nginx
23376 23375  2.1  0.1 nginx
23375     1  1.7  0.0 nginx
23378 23375  1.6  0.0 nginx
 1135  3034  0.9  0.0 cwpsrv
 1133  3034  0.9  0.0 cwpsrv

2) 如何使用 top 命令在 Linux 中查找内存消耗最大的进程

Linux 的 top 命令是用来监视 Linux 系统性能的最好和最知名的命令。它在交互界面上显示运行的系统进程的实时视图。但是,如果要查找内存消耗最大的进程,请 在批处理模式下使用 top 命令

你应该正确地 了解 top 命令输出 以解决系统中的性能问题。

# top -c -b -o +%MEM | head -n 20 | tail -15

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1064 mysql     20   0  886076 209740   8388 S   0.0  5.4  62:41.20 /usr/sbin/mysqld
23396 varnish   20   0  286492 115616  83572 S   0.0  3.0   0:42.24 /usr/sbin/varnishd -P /var/run/varnish.pid -f /etc/varnish/default.vcl -a :82 -T 127.0.0.1:6082 -S /etc/varnish/secret -s malloc,256M
 1105 named     20   0  311712 108204   2424 S   0.0  2.8   0:16.41 /usr/sbin/named -u named -c /etc/named.conf
23377 nobody    20   0  153240  89432   2432 S   0.0  2.3   4:35.74 nginx: worker process
23376 nobody    20   0  147096  83316   2416 S   0.0  2.1   2:18.09 nginx: worker process
23375 root      20   0  131028  66764   1616 S   0.0  1.7   0:01.07 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
23378 nobody    20   0  130988  64592    592 S   0.0  1.7   0:00.51 nginx: cache manager process
 1135 root      20   0   86708  37572   2252 S   0.0  1.0   0:20.18 cwpsrv: worker process
 1133 root      20   0   86708  37544   2212 S   0.0  1.0   0:05.94 cwpsrv: worker process
 3034 root      20   0   86704  36740   1452 S   0.0  0.9   0:00.09 cwpsrv: master process /usr/local/cwpsrv/bin/cwpsrv
 1067 nobody    20   0 1356200  31588   2352 S   0.0  0.8   0:56.06 /usr/local/apache/bin/httpd -k start
  977 nobody    20   0 1356088  31268   2372 S   0.0  0.8   0:30.44 /usr/local/apache/bin/httpd -k start
  968 nobody    20   0 1356216  30544   2348 S   0.0  0.8   0:19.95 /usr/local/apache/bin/httpd -k start

如果你只想查看命令名称而不是命令的绝对路径,请使用下面的 top 命令格式。

# top -b -o +%MEM | head -n 20 | tail -15

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1064 mysql     20   0  886076 210340   8388 S   6.7  5.4  62:40.93 mysqld
23396 varnish   20   0  286492 115616  83572 S   0.0  3.0   0:42.24 cache-main
 1105 named     20   0  311712 108204   2424 S   0.0  2.8   0:16.41 named
23377 nobody    20   0  153240  89432   2432 S  13.3  2.3   4:35.74 nginx
23376 nobody    20   0  147096  83316   2416 S   0.0  2.1   2:18.09 nginx
23375 root      20   0  131028  66764   1616 S   0.0  1.7   0:01.07 nginx
23378 nobody    20   0  130988  64592    592 S   0.0  1.7   0:00.51 nginx
 1135 root      20   0   86708  37572   2252 S   0.0  1.0   0:20.18 cwpsrv
 1133 root      20   0   86708  37544   2212 S   0.0  1.0   0:05.94 cwpsrv
 3034 root      20   0   86704  36740   1452 S   0.0  0.9   0:00.09 cwpsrv
 1067 nobody    20   0 1356200  31588   2352 S   0.0  0.8   0:56.04 httpd
  977 nobody    20   0 1356088  31268   2372 S   0.0  0.8   0:30.44 httpd
  968 nobody    20   0 1356216  30544   2348 S   0.0  0.8   0:19.95 httpd

3) 奖励技巧:如何使用 ps\_mem 命令在 Linux 中查找内存消耗最大的进程

ps\_mem 程序 用于显示每个程序(而不是每个进程)使用的核心内存。该程序允许你检查每个程序使用了多少内存。它根据程序计算私有和共享内存的数量,并以最合适的方式返回已使用的总内存。

它使用以下逻辑来计算内存使用量。总内存使用量 = sum(用于程序进程的专用内存使用量) + sum(用于程序进程的共享内存使用量)。

# ps_mem

 Private  +   Shared  =  RAM used    Program
128.0 KiB +  27.5 KiB = 155.5 KiB    agetty
228.0 KiB +  47.0 KiB = 275.0 KiB    atd
284.0 KiB +  53.0 KiB = 337.0 KiB    irqbalance
380.0 KiB +  81.5 KiB = 461.5 KiB    dovecot
364.0 KiB + 121.5 KiB = 485.5 KiB    log
520.0 KiB +  65.5 KiB = 585.5 KiB    auditd
556.0 KiB +  60.5 KiB = 616.5 KiB    systemd-udevd
732.0 KiB +  48.0 KiB = 780.0 KiB    crond
296.0 KiB + 524.0 KiB = 820.0 KiB    avahi-daemon (2)
772.0 KiB +  51.5 KiB = 823.5 KiB    systemd-logind
940.0 KiB + 162.5 KiB =   1.1 MiB    dbus-daemon
  1.1 MiB +  99.0 KiB =   1.2 MiB    pure-ftpd
  1.2 MiB + 100.5 KiB =   1.3 MiB    master
  1.3 MiB + 198.5 KiB =   1.5 MiB    pickup
  1.3 MiB + 198.5 KiB =   1.5 MiB    bounce
  1.3 MiB + 198.5 KiB =   1.5 MiB    pipe
  1.3 MiB + 207.5 KiB =   1.5 MiB    qmgr
  1.4 MiB + 198.5 KiB =   1.6 MiB    cleanup
  1.3 MiB + 299.5 KiB =   1.6 MiB    trivial-rewrite
  1.5 MiB + 145.0 KiB =   1.6 MiB    config
  1.4 MiB + 291.5 KiB =   1.6 MiB    tlsmgr
  1.4 MiB + 308.5 KiB =   1.7 MiB    local
  1.4 MiB + 323.0 KiB =   1.8 MiB    anvil (2)
  1.3 MiB + 559.0 KiB =   1.9 MiB    systemd-journald
  1.8 MiB + 240.5 KiB =   2.1 MiB    proxymap
  1.9 MiB + 322.5 KiB =   2.2 MiB    auth
  2.4 MiB +  88.5 KiB =   2.5 MiB    systemd
  2.8 MiB + 458.5 KiB =   3.2 MiB    smtpd
  2.9 MiB + 892.0 KiB =   3.8 MiB    bash (2)
  3.3 MiB + 555.5 KiB =   3.8 MiB    NetworkManager
  4.1 MiB + 233.5 KiB =   4.3 MiB    varnishd
  4.0 MiB + 662.0 KiB =   4.7 MiB    dhclient (2)
  4.3 MiB + 623.5 KiB =   4.9 MiB    rsyslogd
  3.6 MiB +   1.8 MiB =   5.5 MiB    sshd (3)
  5.6 MiB + 431.0 KiB =   6.0 MiB    polkitd
 13.0 MiB + 546.5 KiB =  13.6 MiB    tuned
 22.5 MiB +  76.0 KiB =  22.6 MiB    lfd - sleeping
 30.0 MiB +   6.2 MiB =  36.2 MiB    php-fpm (6)
  5.7 MiB +  33.5 MiB =  39.2 MiB    cwpsrv (3)
 20.1 MiB +  25.3 MiB =  45.4 MiB    httpd (5)
104.7 MiB + 156.0 KiB = 104.9 MiB    named
112.2 MiB + 479.5 KiB = 112.7 MiB    cache-main
 69.4 MiB +  58.6 MiB = 128.0 MiB    nginx (4)
203.4 MiB + 309.5 KiB = 203.7 MiB    mysqld
---------------------------------
                        775.8 MiB
=================================

via: https://www.2daygeek.com/linux-find-top-memory-consuming-processes/

作者:Magesh Maruthamuthu 选题:lujun9972 译者:lnrCoder 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Fedora 31 日前发布了。你也许想要升级系统来获得 Fedora 中的最新功能。Fedora 工作站有图形化的升级方式。另外,Fedora 提供了一种命令行方式来将 Fedora 30 升级到 Fedora 31。

将 Fedora 30 工作站升级到 Fedora 31

在该发布不久之后,就会有通知告诉你有可用升级。你可以点击通知打开 GNOME “软件”。或者在 GNOME Shell 选择“软件”。

在 GNOME 软件中选择更新,你应该会看到告诉你有 Fedora 31 更新的提示。

如果你在屏幕上看不到任何内容,请尝试使用左上方的重新加载按钮。在发布后,所有系统可能需要一段时间才能看到可用的升级。

选择下载以获取升级包。你可以继续工作,直到下载完成。然后使用 GNOME “软件”重启系统并应用升级。升级需要时间,因此你可能需要喝杯咖啡,稍后再返回系统。

使用命令行

如果你是从 Fedora 以前的版本升级的,那么你可能对 dnf upgrade 插件很熟悉。这是推荐且支持的从 Fedora 30 升级到 Fedora 31 的方法。使用此插件能让你轻松地升级到 Fedora 31。

1、更新软件并备份系统

在开始升级之前,请确保你安装了 Fedora 30 的最新软件。如果你安装了模块化软件,这点尤为重要。dnf 和 GNOME “软件”的最新版本对某些模块化流的升级过程进行了改进。要更新软件,请使用 GNOME “软件” 或在终端中输入以下命令:

sudo dnf upgrade --refresh

此外,在继续操作之前,请确保备份系统。有关备份的帮助,请参阅 Fedora Magazine 上的备份系列

2、安装 DNF 插件

接下来,打开终端并输入以下命令安装插件:

sudo dnf install dnf-plugin-system-upgrade

3、使用 DNF 开始更新

现在,你的系统是最新的,已经备份并且安装了 DNF 插件,你可以通过在终端中使用以下命令来开始升级:

sudo dnf system-upgrade download --releasever=31

该命令将开始在本地下载计算机的所有升级。如果由于缺乏更新包、损坏的依赖项或已淘汰的软件包而在升级时遇到问题,请在输入上面的命令时添加 ‐-allowerasing 标志。这将使 DNF 删除可能阻止系统升级的软件包。

4、重启并升级

上面的命令下载更新完成后,你的系统就可以重启了。要将系统引导至升级过程,请在终端中输入以下命令:

sudo dnf system-upgrade reboot

此后,你的系统将重启。在许多版本之前,fedup 工具会在内核选择/引导页面上创建一个新选项。使用 dnf-plugin-system-upgrade 软件包,你的系统将重新引导到当前 Fedora 30 使用的内核。这很正常。在内核选择页面之后不久,你的系统会开始升级过程。

现在也许可以喝杯咖啡休息下!升级完成后,系统将重启,你将能够登录到新升级的 Fedora 31 系统。

解决升级问题

有时,升级系统时可能会出现意外问题。如果遇到任何问题,请访问 DNF 系统升级文档,以获取有关故障排除的更多信息。

如果升级时遇到问题,并且系统上安装了第三方仓库,那么在升级时可能需要禁用这些仓库。对于 Fedora 不提供的仓库的支持,请联系仓库的提供者。


via: https://fedoramagazine.org/upgrading-fedora-30-to-fedora-31/

作者:Ben Cotton 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

关于 RPM 软件包构建的上一篇文章中,你了解到了源 RPM 包括软件的源代码以及 spec 文件。这篇文章深入研究了 spec 文件,该文件中包含了有关如何构建 RPM 的指令。同样,本文以 fpaste 为例。

了解源代码

在开始编写 spec 文件之前,你需要对要打包的软件有所了解。在这里,你正在研究 fpaste,这是一个非常简单的软件。它是用 Python 编写的,并且是一个单文件脚本。当它发布新版本时,可在 Pagure 上找到:https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz

如该档案文件所示,当前版本为 0.3.9.2。下载它,以便你查看该档案文件中的内容:

$ wget https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz
$ tar -tvf fpaste-0.3.9.2.tar.gz
drwxrwxr-x root/root         0 2018-07-25 02:58 fpaste-0.3.9.2/
-rw-rw-r-- root/root        25 2018-07-25 02:58 fpaste-0.3.9.2/.gitignore
-rw-rw-r-- root/root      3672 2018-07-25 02:58 fpaste-0.3.9.2/CHANGELOG
-rw-rw-r-- root/root     35147 2018-07-25 02:58 fpaste-0.3.9.2/COPYING
-rw-rw-r-- root/root       444 2018-07-25 02:58 fpaste-0.3.9.2/Makefile
-rw-rw-r-- root/root      1656 2018-07-25 02:58 fpaste-0.3.9.2/README.rst
-rw-rw-r-- root/root       658 2018-07-25 02:58 fpaste-0.3.9.2/TODO
drwxrwxr-x root/root         0 2018-07-25 02:58 fpaste-0.3.9.2/docs/
drwxrwxr-x root/root         0 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/
drwxrwxr-x root/root         0 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/en/
-rw-rw-r-- root/root      3867 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/en/fpaste.1
-rwxrwxr-x root/root     24884 2018-07-25 02:58 fpaste-0.3.9.2/fpaste
lrwxrwxrwx root/root         0 2018-07-25 02:58 fpaste-0.3.9.2/fpaste.py -> fpaste

你要安装的文件是:

  • fpaste.py:应该安装到 /usr/bin/
  • docs/man/en/fpaste.1:手册,应放到 /usr/share/man/man1/
  • COPYING:许可证文本,应放到 /usr/share/license/fpaste/
  • README.rstTODO:放到 /usr/share/doc/fpaste/ 下的其它文档。

这些文件的安装位置取决于文件系统层次结构标准(FHS)。要了解更多信息,可以在这里阅读:http://www.pathname.com/fhs/ 或查看 Fedora 系统的手册页:

$ man hier

第一部分:要构建什么?

现在我们知道了源文件中有哪些文件,以及它们要存放的位置,让我们看一下 spec 文件。你可以在此处查看这个完整的文件:https://src.fedoraproject.org/rpms/fpaste/blob/master/f/fpaste.spec

这是 spec 文件的第一部分:

Name:   fpaste
Version:  0.3.9.2
Release:  3%{?dist}
Summary:  A simple tool for pasting info onto sticky notes instances
BuildArch:  noarch
License:  GPLv3+
URL:    https://pagure.io/fpaste
Source0:  https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz

Requires:    python3

%description
It is often useful to be able to easily paste text to the Fedora
Pastebin at http://paste.fedoraproject.org and this simple script
will do that and return the resulting URL so that people may
examine the output. This can hopefully help folks who are for
some reason stuck without X, working remotely, or any other
reason they may be unable to paste something into the pastebin

NameVersion 等称为标签,它们定义在 RPM 中。这意味着你不能只是随意写点标签,RPM 无法理解它们!需要注意的标签是:

  • Source0:告诉 RPM 该软件的源代码档案文件所在的位置。
  • Requires:列出软件的运行时依赖项。RPM 可以自动检测很多依赖项,但是在某些情况下,必须手动指明它们。运行时依赖项是系统上必须具有的功能(通常是软件包),才能使该软件包起作用。这是 dnf 在安装此软件包时检测是否需要拉取其他软件包的方式。
  • BuildRequires:列出了此软件的构建时依赖项。这些通常必须手动确定并添加到 spec 文件中。
  • BuildArch:此软件为该计算机体系结构所构建。如果省略此标签,则将为所有受支持的体系结构构建该软件。值 noarch 表示该软件与体系结构无关(例如 fpaste,它完全是用 Python 编写的)。

本节提供有关 fpaste 的常规信息:它是什么,正在将什么版本制作为 RPM,其许可证等等。如果你已安装 fpaste,并查看其元数据时,则可以看到该 RPM 中包含的以下信息:

$ sudo dnf install fpaste
$ rpm -qi fpaste
Name        : fpaste
Version     : 0.3.9.2
Release     : 2.fc30
...

RPM 会自动添加一些其他标签,以代表它所知道的内容。

至此,我们掌握了要为其构建 RPM 的软件的一般信息。接下来,我们开始告诉 RPM 做什么。

第二部分:准备构建

spec 文件的下一部分是准备部分,用 %prep 代表:

%prep
%autosetup

对于 fpaste,这里唯一的命令是 %autosetup。这只是将 tar 档案文件提取到一个新文件夹中,并为下一部分的构建阶段做好了准备。你可以在此处执行更多操作,例如应用补丁程序,出于不同目的修改文件等等。如果你查看过 Python 的源 RPM 的内容,那么你会在那里看到许多补丁。这些都将在本节中应用。

通常,spec 文件中带有 前缀的所有内容都是 RPM 以特殊方式解释的宏或标签。这些通常会带有大括号,例如 %{example}

第三部分:构建软件

下一部分是构建软件的位置,用 %build 表示。现在,由于 fpaste 是一个简单的纯 Python 脚本,因此无需构建。因此,这里是:

%build
#nothing required

不过,通常来说,你会在此处使用构建命令,例如:

configure; make

构建部分通常是 spec 文件中最难的部分,因为这是从源代码构建软件的地方。这要求你知道该工具使用的是哪个构建系统,该系统可能是许多构建系统之一:Autotools、CMake、Meson、Setuptools(用于 Python)等等。每个都有自己的命令和语法样式。你需要充分了解这些才能正确构建软件。

第四部分:安装文件

软件构建后,需要在 %install 部分中安装它:

%install
mkdir -p %{buildroot}%{_bindir}
make install BINDIR=%{buildroot}%{_bindir} MANDIR=%{buildroot}%{_mandir}

在构建 RPM 时,RPM 不会修改你的系统文件。在一个可以正常运行的系统上添加、删除或修改文件的风险太大。如果发生故障怎么办?因此,RPM 会创建一个专门打造的文件系统并在其中工作。这称为 buildroot。 因此,在 buildroot 中,我们创建由宏 %{_bindir} 代表的 /usr/bin 目录,然后使用提供的 Makefile 将文件安装到其中。

至此,我们已经在专门打造的 buildroot 中安装了 fpaste 的构建版本。

第五部分:列出所有要包括在 RPM 中的文件

spec 文件其后的一部分是文件部分:%files。在这里,我们告诉 RPM 从该 spec 文件创建的档案文件中包含哪些文件。fpaste 的文件部分非常简单:

%files
%{_bindir}/%{name}
%doc README.rst TODO
%{_mandir}/man1/%{name}.1.gz
%license COPYING

请注意,在这里,我们没有指定 buildroot。所有这些路径都是相对路径。%doc%license命令做的稍微多一点,它们会创建所需的文件夹,并记住这些文件必须放在那里。

RPM 很聪明。例如,如果你在 %install 部分中安装了文件,但未列出它们,它会提醒你。

第六部分:在变更日志中记录所有变更

Fedora 是一个基于社区的项目。许多贡献者维护或共同维护软件包。因此,当务之急是不要被软件包做了哪些更改所搞混。为了确保这一点,spec 文件包含的最后一部分是变更日志 %changelog

%changelog
* Thu Jul 25 2019 Fedora Release Engineering < ...> - 0.3.9.2-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

* Thu Jan 31 2019 Fedora Release Engineering < ...> - 0.3.9.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild

* Tue Jul 24 2018 Ankur Sinha  - 0.3.9.2-1
- Update to 0.3.9.2

* Fri Jul 13 2018 Fedora Release Engineering < ...> - 0.3.9.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

* Wed Feb 07 2018 Fedora Release Engineering < ..> - 0.3.9.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

* Sun Sep 10 2017 Vasiliy N. Glazov < ...> - 0.3.9.1-2
- Cleanup spec

* Fri Sep 08 2017 Ankur Sinha  - 0.3.9.1-1
- Update to latest release
- fixes rhbz 1489605
...
....

spec 文件的每项变更都必须有一个变更日志条目。如你在此处看到的,虽然我以维护者身份更新了该 spec 文件,但其他人也做过更改。清楚地记录变更内容有助于所有人知道该 spec 文件的当前状态。对于系统上安装的所有软件包,都可以使用 rpm 来查看其更改日志:

$ rpm -q --changelog fpaste

构建 RPM

现在我们准备构建 RPM 包。如果要继续执行以下命令,请确保遵循上一篇文章中的步骤设置系统以构建 RPM。

我们将 fpaste 的 spec 文件放置在 ~/rpmbuild/SPECS 中,将源代码档案文件存储在 ~/rpmbuild/SOURCES/ 中,现在可以创建源 RPM 了:

$ cd ~/rpmbuild/SPECS
$ wget https://src.fedoraproject.org/rpms/fpaste/raw/master/f/fpaste.spec

$ cd ~/rpmbuild/SOURCES
$ wget https://pagure.io/fpaste/archive/0.3.9.2/fpaste-0.3.9.2.tar.gz

$ cd ~/rpmbuild/SOURCES
$ rpmbuild -bs fpaste.spec
Wrote: /home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm

让我们看一下结果:

$ ls ~/rpmbuild/SRPMS/fpaste*
/home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm

$ rpm -qpl ~/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm
fpaste-0.3.9.2.tar.gz
fpaste.spec

我们看到源 RPM 已构建。让我们同时构建源 RPM 和二进制 RPM:

$ cd ~/rpmbuild/SPECS
$ rpmbuild -ba fpaste.spec
..
..
..

RPM 将向你显示完整的构建输出,并在我们之前看到的每个部分中详细说明它的工作。此“构建日志”非常重要。当构建未按预期进行时,我们的打包人员将花费大量时间来遍历它们,以跟踪完整的构建路径来查看出了什么问题。

就是这样!准备安装的 RPM 应该位于以下位置:

$ ls ~/rpmbuild/RPMS/noarch/
fpaste-0.3.9.2-3.fc30.noarch.rpm

概括

我们已经介绍了如何从 spec 文件构建 RPM 的基础知识。这绝不是一份详尽的文档。实际上,它根本不是文档。它只是试图解释幕后的运作方式。简短回顾一下:

  • RPM 有两种类型:源 RPM 和 二进制 RPM。
  • 二进制 RPM 包含要安装以使用该软件的文件。
  • 源 RPM 包含构建二进制 RPM 所需的信息:完整的源代码,以及 spec 文件中的有关如何构建 RPM 的说明。
  • spec 文件包含多个部分,每个部分都有其自己的用途。 在这里,我们已经在安装好的 Fedora 系统中本地构建了 RPM。虽然这是个基本的过程,但我们从存储库中获得的 RPM 是建立在具有严格配置和方法的专用服务器上的,以确保正确性和安全性。这个 Fedora 打包流程将在以后的文章中讨论。

你想开始构建软件包,并帮助 Fedora 社区维护我们提供的大量软件吗?你可以从这里开始加入软件包集合维护者

如有任何疑问,请发布到 Fedora 开发人员邮件列表,我们随时乐意为你提供帮助!

参考

这里有一些构建 RPM 的有用参考:


via: https://fedoramagazine.org/how-rpm-packages-are-made-the-spec-file/

作者:Ankur Sinha FranciscoD 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

上周,我一直在做一个 SQL 网站(https://sql-steps.wizardzines.com/,一个 SQL 示例列表)。我使用 sqlite 运行网站上的所有查询,并且我想在其中一个例子(这个)中使用窗口函数。

但是我使用的是 Ubuntu 18.04 中的 sqlite 版本,它太旧了,不支持窗口函数。所以我需要升级 sqlite!

事实证明,这个过程超麻烦(如通常一样),但是非常有趣!我想起了一些有关可执行文件和共享库如何工作的信息,结论令人满意。所以我想在这里写下来。

(剧透:https://www.sqlite.org/howtocompile.html 中解释了如何编译 SQLite,它只需花费 5 秒左右,这比我平时从源码编译的体验容易了许多。)

尝试 1:从它的网站下载 SQLite 二进制文件

SQLite 的下载页面有一个用于 Linux 的 SQLite 命令行工具的二进制文件的链接。我下载了它,它可以在笔记本电脑上运行,我以为这就完成了。

但是后来我尝试在构建服务器(Netlify) 上运行它,得到了这个极其奇怪的错误消息:“File not found”。我进行了追踪,并确定 execve 返回错误代码 ENOENT,这意味着 “File not found”。这有点令人发狂,因为该文件确实存在,并且有正确的权限。

我搜索了这个问题(通过搜索 “execve enoen”),找到了这个 stackoverflow 中的答案,它指出要运行二进制文件,你不仅需要二进制文件存在!你还需要它的加载程序才能存在。(加载程序的路径在二进制文件内部)

要查看加载程序的路径,可以使用 ldd,如下所示:

$ ldd sqlite3
    linux-gate.so.1 (0xf7f9d000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7f70000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7e6e000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7e4f000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7c73000)
    /lib/ld-linux.so.2

所以 /lib/ld-linux.so.2 是加载程序,而该文件在构建服务器上不存在,可能是因为 Xenial(Xenial 是 Ubuntu 16.04,本文应该使用的是 18.04 “Bionic Beaver”)安装程序不支持 32 位二进制文​​件(?),因此我需要尝试一些不同的东西。

尝试 2:安装 Debian sqlite3 软件包

好吧,我想我也许可以安装来自 debian testing 的 sqlite 软件包。尝试从另一个我不使用的 Debian 版本安装软件包并不是一个好主意,但是出于某种原因,我还是决定尝试一下。

这次毫不意外地破坏了我计算机上的 sqlite(这也破坏了 git),但我设法通过 sudo dpkg --purge --force-all libsqlite3-0 恢复了,并使所有依赖于 sqlite 的软件再次工作。

尝试 3:提取 Debian sqlite3 软件包

我还尝试仅从 Debian sqlite 软件包中提取 sqlite3 二进制文件并运行它。毫不意外,这也行不通,但这个更容易理解:我有旧版本的 libreadline(.so.7),但它需要 .so.8

$ ./usr/bin/sqlite3
./usr/bin/sqlite3: error while loading shared libraries: libreadline.so.8: cannot open shared object file: No such file or directory

尝试 4:从源代码进行编译

我花费这么多时间尝试下载 sqlite 二进制的原因是我认为从源代码编译 sqlite 既烦人又耗时。但是显然,下载随便一个 sqlite 二进制文件根本不适合我,因此我最终决定尝试自己编译它。

这有指导:如何编译 SQLite。它是宇宙中最简单的东西。通常,编译的感觉是类似这样的:

  • 运行 ./configure
  • 意识到我缺少依赖
  • 再次运行 ./configure
  • 运行 make
  • 编译失败,因为我安装了错误版本的依赖
  • 去做其他事,之后找到二进制文件

编译 SQLite 的方式如下:

所有代码都在一个文件(sqlite.c)中,并且没有奇怪的依赖项!太奇妙了。

对我而言,我实际上并不需要线程支持或 readline 支持,因此我用编译页面上的说明来创建了一个非常简单的二进制文件,它仅使用了 libc 而没有其他共享库。

$ ldd sqlite3
    linux-vdso.so.1 (0x00007ffe8e7e9000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbea4988000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fbea4d79000)

这很好,因为它使体验 sqlite 变得容易

我认为 SQLite 的构建过程如此简单很酷,因为过去我很乐于编辑 sqlite 的源码来了解其 B 树的实现方式。

鉴于我对 SQLite 的了解,这并不令人感到意外(它在受限环境/嵌入式中确实可以很好地工作,因此可以以一种非常简单/最小的方式进行编译是有意义的)。 但这真是太好了!


via: https://jvns.ca/blog/2019/10/28/sqlite-is-really-easy-to-compile/

作者:Julia Evans 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出