主页 / user-65444

mpb's questions

Martin Hope
mpb
Asked: 2022-02-25 15:22:16 +0800 CST
  • 2

在 Linux 上，该命令lsblk -o partlabel将显示partlabel块设备。

我以前gdisk换过一个partlabel。

更改后，lsblk仍报告partlabel.

（旁白：路径/dev/disk/by-partlabel/*也仍在使用旧partlabel值。）

有没有办法刷新缓存，以便lsblk报告新的值partlabel？

我不确定缓存的确切位置。它可能是 udev、sysfs 或其他地方。

相比之下，blkid正确报告新的partlabel. 但是，我希望我可以避免切换到blkid（出于各种原因）。

（旁白：重新启动可能会更新这些partlabel值。但如果可能的话，我宁愿避免重新启动。）

linux udev
Martin Hope
mpb
Asked: 2021-12-02 16:46:54 +0800 CST
  • 1

我在 Ubuntu 上运行ss-server代理（从包中）。shadowsocks-libev

我相信ss-server是由systemd. ss-server以用户身份运行shadows+，如下所示：

$  ps u -C ss-server
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
shadows+  719498  0.0  0.7  16244  7976 ?        Ss   Nov30   0:06 /usr/bin/ss-server -c /etc/shadowsocks-libev/config.json
$  ps un -C ss-server
    USER     PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   64677  719498  0.0  0.7  16244  7976 ?        Ss   Nov30   0:06 /usr/bin/ss-server -c /etc/shadowsocks-libev/config.json

该用户在哪里shadows+定义？我没有在 中看到该用户/etc/passwd。

实际用户名可能类似于shadowsocks，并且被截断为 8 个字符。但即便如此，该用户也不存在于/etc/passwd.

所以问题仍然存在，这个用户在哪里定义？

更新：

针对 telcoM 的回答，我将提供额外的背景信息来解释我为什么对shadowsocks-libev用户感到好奇。

ss-server作为用户 64677 运行（至少目前）。

ss-server读取其配置文件/etc/shadowsocks-libev/config.json。

任何用户都可以读取此配置文件（默认安装在 Ubuntu 上）。

此配置文件包含（默认情况下）一个半机密密码（可能是在系统上安装软件包时生成的）。

理想情况下，只有ss-server程序和任何ss-client连接的程序ss-server会知道这个密码。

因此，任何用户都可以读取配置文件这一事实在 IMO 中是一个（轻微的？）安全漏洞。

我正在考虑更改/etc/shadowsocks-libev/config.json（或其父目录）的所有权。所以我想知道这个数字用户 ID 是否会在重新启动后保持稳定。

第二次更新：

感谢电信公司的回答和评论，我找到了以下文件：
/etc/systemd/system/multi-user.target.wants/shadowsocks-libev.service

#  This file is part of shadowsocks-libev.
#
#  Shadowsocks-libev is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 3 of the License, or
#  (at your option) any later version.
#
#  This file is default for Debian packaging. See also
#  /etc/default/shadowsocks-libev for environment variables.

[Unit]
Description=Shadowsocks-libev Default Server Service
Documentation=man:shadowsocks-libev(8)
After=network-online.target

[Service]
Type=simple
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
DynamicUser=true
EnvironmentFile=/etc/default/shadowsocks-libev
LimitNOFILE=32768
ExecStart=/usr/bin/ss-server -c $CONFFILE $DAEMON_ARGS

[Install]
WantedBy=multi-user.target

请注意，上述文件包含DynamicUser=true. 该文件缺少StateDirectory=条目。

systemd users
Martin Hope
mpb
Asked: 2021-09-05 15:11:20 +0800 CST
  • 0

从挂起唤醒后，我的 Ubuntu 21.04 系统出现了网络问题。我猜大约 50% 的 IP 套接字失败了。这包括ssh和的失败ping。“失败”是指连接尝试阻塞，然后最终超时。（旁白：也许ping不使用套接字？）我相信所有尝试网络访问的程序都遇到了相同的失败率。

几个星期以来，我每晚都在暂停系统。今天是我复工后第一次遇到问题。

我重新启动了系统，这似乎已经解决了问题（至少在它再次发生之前）。

重新启动后，我在syslog.

我在每次挂起时看到以下两行：

Sep  4 09:00:18 hostname kernel: [896165.908582] igc 0000:b0:00.0: no suspend buffer for PTM
Sep  4 09:00:18 hostname kernel: [896165.908589] igc 0000:af:00.0: no suspend buffer for PTM

（旁白：虽然上述行指的是暂停之前发生的事件，但我相信日志条目是在系统恢复后才创建的。因此，这些事件实际上发生在指定时间之前的几个小时。）

每份简历上都有两条相同的行：

Sep  4 09:00:18 hostname kernel: [896166.257107] igc 0000:af:00.0: no suspend buffer for PTM
Sep  4 09:00:18 hostname kernel: [896166.257177] igc 0000:b0:00.0: no suspend buffer for PTM

（旁白：可能是因为系统有两个内置网卡，所以有两条线？）

以下是仅在我最近的简历中出现的日志条目，也就是网络问题开始的时候：

Sep  4 09:00:19 hostname kernel: [896168.214463] igc 0000:b0:00.0 enp176s0: Register Dump
Sep  4 09:00:19 hostname kernel: [896168.214467] igc 0000:b0:00.0 enp176s0: Register Name   Value
Sep  4 09:00:19 hostname kernel: [896168.214478] igc 0000:b0:00.0 enp176s0: CTRL            081c0641
Sep  4 09:00:19 hostname kernel: [896168.214481] igc 0000:b0:00.0 enp176s0: STATUS          40380401
Sep  4 09:00:19 hostname kernel: [896168.214483] igc 0000:b0:00.0 enp176s0: CTRL_EXT        10000040
Sep  4 09:00:19 hostname kernel: [896168.214486] igc 0000:b0:00.0 enp176s0: MDIC            18017949
Sep  4 09:00:19 hostname kernel: [896168.214488] igc 0000:b0:00.0 enp176s0: ICR             00000001
Sep  4 09:00:19 hostname kernel: [896168.214490] igc 0000:b0:00.0 enp176s0: RCTL            04408022
Sep  4 09:00:19 hostname kernel: [896168.214497] igc 0000:b0:00.0 enp176s0: RDLEN[0-3]      00001000 00001000 00001000 00001000
Sep  4 09:00:19 hostname kernel: [896168.214504] igc 0000:b0:00.0 enp176s0: RDH[0-3]        00000000 00000000 00000000 00000000
Sep  4 09:00:19 hostname kernel: [896168.214511] igc 0000:b0:00.0 enp176s0: RDT[0-3]        000000ff 000000ff 000000ff 000000ff
Sep  4 09:00:19 hostname kernel: [896168.214518] igc 0000:b0:00.0 enp176s0: RXDCTL[0-3]     02040808 02040808 02040808 02040808
Sep  4 09:00:19 hostname kernel: [896168.214525] igc 0000:b0:00.0 enp176s0: RDBAL[0-3]      2e35d000 51576000 337b2000 29a5b000
Sep  4 09:00:19 hostname kernel: [896168.214532] igc 0000:b0:00.0 enp176s0: RDBAH[0-3]      00000001 00000001 00000002 00000001
Sep  4 09:00:19 hostname kernel: [896168.214534] igc 0000:b0:00.0 enp176s0: TCTL            a50400fa
Sep  4 09:00:19 hostname kernel: [896168.214541] igc 0000:b0:00.0 enp176s0: TDBAL[0-3]      2e35d000 51576000 337b2000 29a5b000
Sep  4 09:00:19 hostname kernel: [896168.214548] igc 0000:b0:00.0 enp176s0: TDBAH[0-3]      00000001 00000002 00000001 00000001
Sep  4 09:00:19 hostname kernel: [896168.214555] igc 0000:b0:00.0 enp176s0: TDLEN[0-3]      00001000 00001000 00001000 00001000
Sep  4 09:00:19 hostname kernel: [896168.214562] igc 0000:b0:00.0 enp176s0: TDH[0-3]        00000007 00000009 00000004 00000000
Sep  4 09:00:19 hostname kernel: [896168.214568] igc 0000:b0:00.0 enp176s0: TDT[0-3]        0000000d 00000011 00000004 00000001
Sep  4 09:00:19 hostname kernel: [896168.214575] igc 0000:b0:00.0 enp176s0: TXDCTL[0-3]     02100108 02100108 02100108 02100108
Sep  4 09:00:19 hostname kernel: [896168.214576] igc 0000:b0:00.0 enp176s0: Reset adapter

然后有很多（超过 19,000 个）条目，如下所示：

Sep  4 09:01:22 hostname kernel: [896231.189109] igc 0000:b0:00.0 enp176s0: Detected Tx Unit Hang
Sep  4 09:01:22 hostname kernel: [896231.189109]   Tx Queue             <1>
Sep  4 09:01:22 hostname kernel: [896231.189109]   TDH                  <9>
Sep  4 09:01:22 hostname kernel: [896231.189109]   TDT                  <9>
Sep  4 09:01:22 hostname kernel: [896231.189109]   next_to_use          <9>
Sep  4 09:01:22 hostname kernel: [896231.189109]   next_to_clean        <9>
Sep  4 09:01:22 hostname kernel: [896231.189109] buffer_info[next_to_clean]
Sep  4 09:01:22 hostname kernel: [896231.189109]   time_stamp           <10d596f4c>
Sep  4 09:01:22 hostname kernel: [896231.189109]   next_to_watch        <000000002b25478e>
Sep  4 09:01:22 hostname kernel: [896231.189109]   jiffies              <10d59ad90>
Sep  4 09:01:22 hostname kernel: [896231.189109]   desc.status          <0>

我的问题是，除了完全重新启动系统之外，还有什么方法可以从命令行手动重置/重新启动网络接口？

该系统是一个桌面工作站，所以我可以使用键盘。

重新启动后，我意识到也许我应该尝试重新挂起并重新唤醒系统。但我只是在完全重启后才想到这一点。

linux networking
Martin Hope
mpb
Asked: 2018-11-10 16:19:48 +0800 CST
  • 3

我正在尝试让非 root 用户挂载/proc在 Linux 用户命名空间中。

如果我通过创建命名空间clone()，那么我可以挂载/proc.

但是，如果我通过 创建命名空间unshare()，则调用mount()失败并显示Operation not permitted.

为什么mount()创建命名空间时的行为与创建clone()不同unshare()？

下面的代码演示了差异。

#define   _GNU_SOURCE
#include  <errno.h>
#include  <sched.h>
#include  <stdio.h>
#include  <stdlib.h>
#include  <string.h>
#include  <unistd.h>
#include  <sys/syscall.h>
#include  <sys/mount.h>
#include  <sys/types.h>
#include  <sys/stat.h>
#include  <sys/wait.h>
#include  <fcntl.h>


#define STACK_SIZE (1024 * 1024)

static char child_stack[STACK_SIZE];    /* Space for child's stack */


void  try  ( const char * msg, int rv )  {
  printf ( "%-8s  %6d  %s\n", msg, rv, strerror ( rv < 0 ? errno : 0 ) );
}


int  child  ( void * arg )  {
  try(  "mount_1",   mount   (  "PROC", "/proc", "proc", 0, NULL  ));
  try(  "umount_1",  umount  (  "/proc"                           ));
  return  0;
}


int  main  ()  {

  int  clone_flags  =  0;

  clone_flags  |=  CLONE_NEWNET;
  clone_flags  |=  CLONE_NEWNS;
  clone_flags  |=  CLONE_NEWPID;
  clone_flags  |=  CLONE_NEWUSER;

  try(  "clone",    clone    (  child, child_stack + STACK_SIZE,
                                clone_flags | SIGCHLD, NULL       ));
  try(  "wait",     wait     (  NULL                              ));
  try(  "unshare",  unshare  (  clone_flags                       ));
  try(  "mount_2",  mount    (  "PROC", "/proc", "proc", 0, NULL  ));

  return  0;

}

输出：

clone      31478  Success
mount_1        0  Success
umount_1       0  Success
wait       31478  Success
unshare        0  Success
mount_2       -1  Operation not permitted

我在带有内核的 Ubuntu 18.04 上运行Linux 4.15.0-20-generic。我以非 root 身份运行上述代码。

mount proc
Martin Hope
mpb
Asked: 2017-12-08 14:51:53 +0800 CST
  • 11

我正在配置运行 BeagleBone.org 的 Debian 映像的 BeableBone Black。

我可以看到init（即 systemd）正在侦听端口1880和3000.

debian@beaglebone:~$ sudo netstat -taunp | grep LISTEN
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      978/dnsmasq         
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      852/sshd            
tcp6       0      0 :::53                   :::*                    LISTEN      978/dnsmasq         
tcp6       0      0 :::22                   :::*                    LISTEN      852/sshd            
tcp6       0      0 :::1880                 :::*                    LISTEN      1/init              
tcp6       0      0 :::3000                 :::*                    LISTEN      1/init

以前，init也在监听端口 80。我使用https://stackoverflow.com/a/16570889中的这些命令禁用了它：

systemctl disable bonescript.service
systemctl disable bonescript.socket
systemctl disable bonescript-autorun.service

如何让系统告诉我哪些服务正在侦听端口1880和3000？

debian systemd