深入探究Linux 141: 了解操作系统的核心技术 (linux 141)

作为开源文化的代表之一,Linux操作系统一直以来作为服务器端和嵌入式设备的首选系统平台。因为其可定制性和便捷性而受到广泛的欢迎,并且在全球范围内得到了广泛的应用和推广。而想要深入了解Linux操作系统,必须掌握其核心技术,理解以下几个方面:

1、进程管理

在Linux中,进程是操作系统的核心基本单元。每个进程都是具有独立地址空间和资源分配的程序实例。了解进程管理就是了解如何分配和回收进程的资源。进程管理涉及以下几个核心技术:

a. 进程调度:涉及使进程进入运行状态,并且从进程中获取计算机资源来执行进程代码,同时还要负责将进程从运行状态切换到阻塞或就绪等状态。

b. 进程通信:进程间通信是Linux进程间交互的重要方式。常用的进程通信方式包括共享内存、信号量、管道等。

c. 进程同步:为了避免进程在共享资源访问时互相干扰或更致命的竞争情况,必须通过特殊的同步技术来协调进程的执行顺序。

2、系统调用

Linux是一个用户空间和内核空间共存的操作系统。在Linux内核中,通常会有大量的功能实现,供应用程序调用。系统调用就是基础操作系统服务的一种方式,它为用户层提供接口并使其能够与内核交互。在Linux中,一些通用的系统调用包括打开、读取、写入和关闭文件等。实际上,每个应用程序都是通过系统调用调用内核的某些功能,这使得系统调用的重要性显而易见。

3、文件系统

Linux中的文件系统由一个树状目录结构组成,每个目录都含有零个或多个文件以及零个或多个子目录。文件系统还支持对文件的访问、读取和写入。在Linux中,各种文件系统类型被支持,例如EXT3、EXT4、NTFS等。

4、内存管理

内存管理是Linux操作系统中的一个必不可少的部分,它涉及到操作系统如何分配和管理内存。在Linux中,内存管理包括内存分配、清理和管理,还要确保不会出现过量占用和浪费。总的来说。内存管理是Linux操作系统中重要的贡献之一。

总体而言,掌握这些核心技术至关重要,因为这些知识体系涉及到Linux操作系统的核心部分,其了解程度正直接或间接地影响到Linux操作系统的优化、高效以及稳定性。此外,Linux操作系统的实际应用也需要掌握这些技术,因为开发者需要利用这些技术来优化Linux操作系统并提高其性能。

相关问题拓展阅读:

linux 出现 segment fault怎么解决

1. 段错误是什么

一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存空间,例如访问了不存在的内存地址、访问了系统保护的内存地址、访问了只读的内存地址等等情况。这里贴一个对于“段错误”的准确定义(参考Answers.com):

A segmentation fault (often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorolatend to refer to these events as Address or Bus errors.

Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, “segmentation fault” being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.

On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception.

2. 段错误产生的原因

2.1 访问不存在的内存地址

#include

#include

void main()

{

int *ptr = NULL;

*ptr = 0;

}

2.2 访问系统保护的内存地址

#include

#include

void main()

{

int *ptr = (int *)0;

*ptr = 100;

}

2.3 访问只读的内存地址

#include

#include

#include

void main()

{

char *ptr = “test”;

strcpy(ptr, “TEST”);

}

2.4 栈溢出

#include

#include

void main()

{

main();

}

等等其他原因。

3. 段错误信息的获取

程序发生段错误时,提示信息很少,下面有几种查看段错误的发生信息的途径。

3.1 dmesg

dmesg可以在应用程序crash掉时,显示内核中保存的相关信息。如下所示,通过dmesg命令可以查看发生段错误的程序名称、引起段错误发生的内存地址、指令指针地址、堆栈指针地址、错误代码、错误原因等。以程序2.3为例:

panfeng@ubuntu:~/segfault$ dmesg

segfault3: segfault at 80484e0 ip 00d2906a sp bfbbec3c error 7 in libc-2.10.1.so

3.2 -g

使用gcc编译程序的源码时,加上-g参数,这样可以使得生成的二进制文件中加入可以用于gdb调试的有用信息。以程序2.3为例:

panfeng@ubuntu:~/segfault$ gcc -g -o segfault3 segfault3.c

3.3 nm

使用nm命令列出二进制文件中的符号表,包括符号地址、符号类型、符号名等,这样可以帮助定位在哪里发生了段错误。以程序2.3为例:

panfeng@ubuntu:~/segfault$ nm segfault3

08049f20 d _DYNAMIC

08049ff4 d _GLOBAL_OFFSET_TABLE_

080484dc R _IO_stdin_used

w _Jv_RegisterClasses

08049f10 d __CTOR_END__

08049f0c d __CTOR_LIST__

08049f18 D __DTOR_END__

08049f14 d __DTOR_LIST__

080484ec r __FRAME_END__

08049f1c d __JCR_END__

08049f1c d __JCR_LIST__

0804a014 A __bss_start

0804a00c D __data_start

t __do_global_ctors_aux

t __do_global_dtors_aux

0804a010 D __dso_handle

w __gmon_start__

a T __i686.get_pc_thunk.bx

08049f0c d __init_array_end

08049f0c d __init_array_start

T __libc_csu_fini

T __libc_csu_init

U __libc_start_main@@GLIBC_2.0

0804a014 A _edata

0804a01c A _end

080484bc T _fini

080484d8 R _fp_hw

080482bc T _init

T _start

0804a014 b completed.6990

0804a00c W data_start

0804a018 b dtor_idx.6992

080483c0 t frame_dummy

080483e4 T main

U memcpy@@GLIBC_2.0

3.4 ldd

使用ldd命令查看二进制程序的共享链接库依赖,包括库的名称、起始地址,这样可以确定段错误到底是发生在了自己的程序中还是依赖的共享库中。以程序2.3为例:

panfeng@ubuntu:~/segfault$ ldd ./segfault3

linux-gate.so.1 => (0x00e08000)

libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x)

/lib/ld-linux.so.2 (0x)

4. 段错误的调试方法

4.1 使用printf输出信息

这个是看似最简单但往往很多情况下十分有效的调试方式,也许可以说是程序员用的最多的调试方式。简单来说,就是在程序的重要代码附近加上像printf这类输出信息,这样可以跟踪并打印出段错误在代码中可能出现的位置。

为了方便使用这种方法,可以使用条件编译指令#ifdef DEBUG和#endif把printf函数包起来。这样在程序编译时,如果加上-DDEBUG参数就能查看调试信息;否则不加该参数就不会显示调试信息。

4.2 使用gcc和gdb

4.2.1 调试步骤

1、为了能够使用gdb调试程序,在编译阶段加上-g参数,以程序2.3为例:

panfeng@ubuntu:~/segfault$ gcc -g -o segfault3 segfault3.c

2、使用gdb命令调试程序:

panfeng@ubuntu:~/segfault$ gdb ./segfault3

GNU gdb (GDB) 7.0-ubuntu

Copyright (C) 2023 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type “show copying”

and “show warranty” for details.

This GDB was configured as “i486-linux-gnu”.

For bug reporting instructions, please see:

Reading symbols from /home/panfeng/segfault/segfault3…done.

(gdb)

3、进入gdb后,运行程序:

(gdb) run

Starting program: /home/panfeng/segfault/segfault3

Program received signal SIGSEGV, Segmentation fault.

0x001a306a in memcpy () from /lib/tls/i686/cmov/libc.so.6

(gdb)

从输出看出,程序2.3收到SIGSEGV信号,触发段错误,并提示地址0x001a306a、调用memcpy报的错,位于/lib/tls/i686/cmov/libc.so.6库中。

4、完成调试后,输入quit命令退出gdb:

(gdb) quit

A debugging session is active.

Inferior 1 will be killed.

Quit anyway? (y or n) y

4.2.2 适用场景

1、仅当能确定程序一定会发生段错误的情况下使用。

2、当程序的源码可以获得的情况下,使用-g参数编译程序。

3、一般用于测试阶段,生产环境下gdb会有副作用:使程序运行减慢,运行不够稳定,等等。

4、即使在测试阶段,如果程序过于复杂,gdb也不能处理。

4.3 使用core文件和gdb

在4.2节中提到段错误会触发SIGSEGV信号,通过man 7 signal,可以看到SIGSEGV默认的handler会打印段错误出错信息,并产生core文件,由此我们可以借助于程序异常退出时生成的core文件中的调试信息,使用gdb工具来调试程序中的段错误。

4.3.1 调试步骤

1、在一些Linux版本下,默认是不产生core文件的,首先可以查看一下系统core文件的大小限制:

panfeng@ubuntu:~/segfault$ ulimit -c

2、可以看到默认设置情况下,本机Linux环境下发生段错误时不会自动生成core文件,下面设置下core文件的大小限制(单位为KB):

panfeng@ubuntu:~/segfault$ ulimit -c 1024

panfeng@ubuntu:~/segfault$ ulimit -c

1024

3、运行程序2.3,发生段错误生成core文件:

panfeng@ubuntu:~/segfault$ ./segfault3

段错误 (core dumped)

4、加载core文件,使用gdb工具进行调试:

panfeng@ubuntu:~/segfault$ gdb ./segfault3 ./core

GNU gdb (GDB) 7.0-ubuntu

Copyright (C) 2023 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type “show copying”

and “show warranty” for details.

This GDB was configured as “i486-linux-gnu”.

For bug reporting instructions, please see:

Reading symbols from /home/panfeng/segfault/segfault3…done.

warning: Can’t read pathname for load map: 输入/输出错误.

Reading symbols from /lib/tls/i686/cmov/libc.so.6…(no debugging symbols found)…done.

Loaded symbols for /lib/tls/i686/cmov/libc.so.6

Reading symbols from /lib/ld-linux.so.2…(no debugging symbols found)…done.

Loaded symbols for /lib/ld-linux.so.2

Core was generated by `./segfault3′.

Program terminated with signal 11, Segmentation fault.

#0 0xa in memcpy () from /lib/tls/i686/cmov/libc.6

从输出看出,同4.2.1中一样的段错误信息。

5、完成调试后,输入quit命令退出gdb:

(gdb) quit

4.3.2 适用场景

1、适合于在实际生成环境下调试程序的段错误(即在不用重新发生段错误的情况下重现段错误)。

2、当程序很复杂,core文件相当大时,该方法不可用。

4.4 使用objdump

4.4.1 调试步骤

1、使用dmesg命令,找到最近发生的段错误输出信息:

panfeng@ubuntu:~/segfault$ dmesg

… …

segfault3: segfault at 80484e0 ipa sp bfc1cd6c error 7 in libc-2.10.1.so

其中,对我们接下来的调试过程有用的是发生段错误的

2、使用objdump生成二进制的相关信息,重定向到文件中:

panfeng@ubuntu:~/segfault$ objdump -d ./segfault3 > segfault3Dump

其中,生成的segfault3Dump文件中包含了二进制文件的segfault3的汇编代码。

3、在segfault3Dump文件中查找发生段错误的地址:

panfeng@ubuntu:~/segfault$ grep -n -A 10 -B 10 “80484e0” ./segfault3Dump

df: ff dcall *%eax

e1: cleave

e2: cret

e3: nop

125-

e4 :

e4: push %ebp

e5:emov %esp,%ebp

e7:e4 f and $0xfffffff0,%esp

ea:ec sub $0x20,%esp

131: 80483ed: cc emovl $0x80484e0,0x1c(%esp)

f4:

f5: b8 emov $0x80484e5,%eax

fa: cmovl $0x5,0x8(%esp)

:

: mov %eax,0x4(%esp)

: 8bcmov 0x1c(%esp),%eax

a: mov %eax,(%esp)

d: e8 0a ff ff ffcallc

: cleave

: cret

通过对以上汇编代码分析,得知段错误发生main函数,对应的汇编指令是movl $0x80484e0,0x1c(%esp),接下来打开程序的源码,找到汇编指令对应的源码,也就定位到段错误了。

4.4.2 适用场景

1、不需要-g参数编译,不需要借助于core文件,但需要有一定的汇编语言基础。

2、如果使用了gcc编译优化参数(-O1,-O2,-O3)的话,生成的汇编指令将会被优化,使得调试过程有些难度。

4.5 使用catchsegv

catchsegv命令专门用来扑获段错误,它通过动态加载器(ld-linux.so)的预加载机制(PRELOAD)把一个事先写好的库(/lib/libSegFault.so)加载上,用于捕捉断错误的出错信息。

panfeng@ubuntu:~/segfault$ catchsegv ./segfault3

Segmentation fault (core dumped)

*** Segmentation fault

Register dump:

EAX:EBX: 00fb3ff4 ECX:EDX:

ESI:e5 EDI:e0 EBP: bfb7ad38 ESP: bfb7ad0c

EIP: 00ee806a EFLAGS:

CS:DS: 007b ES: 007b FS:GS:SS: 007b

Trap:e Error:OldMask:

ESP/signal: bfb7ad0c CR2:e0

Backtrace:

/lib/libSegFault.so

??:0(??)

/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)

/build/buildd/eglibc-2.10.1/csu/../sysdeps/i386/elf/start.S:122(_start)

Memory map:

Linux 系统下面出现:Segment fault(段错误)提示信息,有时候是由于你自己在编写程序的过程中,有数组越界、或者是内存泄漏(例如: 引用了空指针)等原因造成的。具体是哪一种情况,就需要自己仔细查看自己编写的源程序,到底哪里有程序漏洞。

Linux是一套免费使用和自由传播的类Unix操作系统,是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的操作系统。它能运行主要的UNIX工具软件、应用程序和网络协议。它支持32位和64位硬件。Linux继承了Unix以网络为核心的设计思想,是一个性能稳定的多用户网络操作系统。

Linux操作系统诞生于1991 年10 月5 日(这是之一次正式向外公布时间)。Linux存在着许多不同的Linux版本,但它们都使用了Linux内核。Linux可安装在各种计算机硬件设备中,比如手机、平板电脑、路由器、视频游戏控制台、台式计算机、大型机和超级计算机。

严格来讲,Linux这个词本身只表示Linux内核,但实际上人们已经习惯了用Linux来形容整个基于Linux内核,并且使用GNU工程各种工具和数据库的操作系统。

Ubuntu18.04boot空间不足,删除旧内核又显示有未满足的依赖关系?

一般按照网上教程安装闷亩拍ubuntu的时候,在配置分区时一般都只给分到200M的空间,平时自个喜好是分400M,但这次脑壳儿疼分了200m,系统update了几次,旧的内核版本没清理,导致了boot空间不足。找了一下方法,总结下解决的过程。

尝试无脑的自动清理命令

sudo apt-get autoclean

sudo apt-get clean

sudo apt-get autoclean

可能存在一些问题,比如将一些必要文件删除???有风险,所以选择了保守的方式。

正常的删除步骤

进入到/boot目录下

cd /boot

First >查看自己系统已经安装的内核版本,下图是我自个已安装的内核版本。

sudo dpkg –get-selections |grep linux-image

Second>查看正在使用的内核版本。为4.13.0-45-generic.

sudo uname -a

Third>删除旧的内核版本

内核版本显示为install,表示系统已经安装了相应的内核,使用purge命令删除相应的内核。

sudo apt purge linux-image-4.4.0-130-generic

内核版本显示为deinstall,耐悔表示系统没有安装此内核,但是在配置文件中还残留它的信息,也有可能是以前卸载的时候不彻底。

sudo dpkg -P linux-image-extra-4.4.0-128-generic

正常情况下,就已经清理完成辣。输入df查看/boot的已用百分比。

作者:Gene_Chung

链接:

来源:简书

简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

附录:可能的错误以及解决方法

这里列举了一些情况,希望能有帮助。

执行卸载命令(sudo apt purge linux-image-4.4.0-128-generic)时报错:

正在读取软件包列表… 完成

正在分析软件包的依赖关系树

正在读取状态信息… 完成

您可能需要运行“apt-get -f install”来纠正下列错误:

下列软件包有未满足的依赖关系:

linux-image-extra-4.4.0-128-generic : 依赖: linux-image-4.4.0-128-generic 但是它将不会被安装

linux-image-extra-4.4.0-130-generic : 依赖: linux-image-4.4.0-130-generic 但是它将不会被安装

E: 有未能满足的依赖关系。请尝试不指明软件包的名字来运行“apt-get -f install”蚂羡(也可以指定一个解决办法)。

修复办法:

根据错误提示输入执行命令:sudo apt -f install

执行修复命令(sudo apt -f install)时可能报错:

正在读取软件包列表… 完成

正在分析软件包的依赖关系树

正在读取状态信息… 完成

…….

gzip: stdout: No space left on device

E: mkinitramfs failure find 141 cpio 141 gzip 1

update-initramfs: failed for /boot/initrd.img-4.4.0-75-generic with 1.

run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1

dpkg: 处理软件包 linux-image-extra-4.4.0-130-generic (–configure)时出错:

子进程 已安装 post-installation 脚本 返回错误状态 1

在处理时有错误发生:

linux-image-extra-4.4.0-128-generic

linux-image-extra-4.4.0-130-generic

E: Sub-process /usr/bin/dpkg returned an error code (1)

解决办法:

gzip: stdout: No space left on device 说明/boot空间下没有足够的空间了。

因为:为了省出更多boot空间需要删除旧的内核,删除旧的内核时又需要修复一些依赖,修复依赖就需要下载依赖包,而boot空间下本来就满了……emmm,想想这问题脑壳又疼了,那么只能暂时将一些不这么重要的文件迁移到其他的文件夹下面辣。那迁移出去的文件怎么办?在解决问题后再迁移回来呗。。。

嗯。。。修复完了之后,再次执行卸载命令(sudo apt purge linux-image-),删除旧内核/boot空间不足问题就解决辣。

更多Linux知识可以参考《Linux就该这么学》

/boot 独立分区?

多大?一般推荐 800M 吧

关于linux 141的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。


数据运维技术 » 深入探究Linux 141: 了解操作系统的核心技术 (linux 141)