mastouille.fr est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Mastouille est une instance Mastodon durable, ouverte, et hébergée en France.

Administré par :

Statistiques du serveur :

582
comptes actifs

#systemadministration

3 messages2 participants0 message aujourd’hui

I've been busy preparing my community course "Basic Linux System Administration" for a few weeks now. The next instructor-led cohort starts in September.

Here's the public chapter on text editing with vim. You can use it outside the course context, simply as a concise #vim tutorial.

courses.monospacementor.com/co

DevOps/SRE Courses by Monospace MentorText Editing

Did you know FreeBSD includes a built-in utility for scheduling routine maintenance tasks?

From daily security checks to system cleanup jobs, the periodic system helps keep things running smoothly — and it’s easy to customize.

Learn how to use existing periodic scripts and integrate your own in our latest blog:

freebsdfoundation.org/blog/an-

epoll on pidfd

The Linux kernel has an interesting file descriptor called pidfd. As the name imples, it is a file descriptor to a pid or a specific process. The nice thing about it is that is guaranteed to be for the specific process you expected when you got that pidfd. A process ID, or PID, has no reuse guarantees, which means what you think process 1234 is and what the kernel knows what process 1234 is could be different because your process exited and the process IDs have looped around.

pidfds are *odd*, they’re half a “normal” file descriptor and half… something else. That means some file descriptor things work and some fail in odd ways. stat() works, but using them in the first parameter of openat() will fail.

One thing you can do with them is use epoll() on them to get process status, in fact the pidfd_open() manual page says:

A PID file descriptor returned by pidfd_open() (or by clone(2) with the CLONE_PID flag) can be used for the following purposes:

A PID file descriptor can be monitored using poll(2), select(2), and epoll(7). When the process that it refers to terminates, these interfaces indicate the file descriptor as readable.

So if you want to wait until something terminates, then you can just find the pidfd of the process and sit an epoll_wait() onto it. Simple, right? Except its not quite true.

procps issue #386 stated that if you had a list of processes, then pidwait only finds half of them. I’d like to thank Steve the issue reporter for the initial work on this. The odd thing is that for every exited process, you get two epoll events. You get an EPOLLIN first, then a EPOLLIN | EPOLLHUP after that. Steve suggested the first was when the process exits, the second when the process has been collected by the parent.

I have a collection of oddball processes, including ones that make zombies. A zombie is a child that has exited but has not been wait() ed by its parent. In other words, if a parent doesn’t collect its dead child, then the child becomes a zombie. The test program spawns a child, which exits after some seconds. The parent waits longer, calls wait() waits some more then exits. Running pidwait we can see the following epoll events:

  • When the child exits, EPOLLIN on the child is triggered. At this stage the child is a zombie.
  • When the parent calls wait(), then EPOLLIN | EPOLLHUP on the child is triggered.
  • When the parent exits, EPOLLIN then EPOLLIN | EPOLLHUP on the parent is triggered. That is, two events for the one thing.

If you want to use epoll() to know when a process terminates, then you need to decide on what you mean by that:

  • If you mean it has exited, but not collected yet (e.g. a zombie possibly) then you need to select on EPOLLIN only.
  • If you mean the process is fully gone, then EPOLLHUP is a better choice. You can even change the epoll_ctl() call to use this instead.

A “zombie trigger” (EPOLLIN with no subsequent EPOLLHUP) is a bit tricky to work out. There is no guarantee the two events have to be in the same epoll, especially if the parent is a bit tardy on their wait() call.

GitLabpidwait waits for only half of the given processes (#386) · Issues · procps-ng / procps · GitLabApparently pidwait waits for only half of the given processes. bash example to reproduce:

Man! #FreeBSD pkg-upgrade(8) does not find a pending update if given the currently installed package name with version, which is the output of: pkg audit --quiet.

pkg-audit(8) lacks the option to list only the package name sans version. It also lacks the option to find possibly available updates itself. Of course it does.

🤬🖕

As of #pkg v2.1.4, in order to check for pending updates of vulnerable packages, need to strip the version string from the output of pkg-audit(8)😫:

# sh

rc=0
if ! pkg audit --fetch --recursive
then
rc=1
printf "\n# Checking if updates for vulnerable packages are available ...\n"

# "pkg-query(8)" command is used to extract the package name sans version as
# "pkg-upgrade(8)" can only cope with either that or name-version of the
# updated package yet to be installed.
pkg audit --quiet | xargs pkg query '%n' | xargs pkg upgrade --dry-run
fi

exit $rc

Server monitoring 101

I have been running a @yunohost server for ~5 years now, but there is one question I have never been able to answer: how loaded is my server? 👀

I know, I am a terrible sysad (actually, I am not a sysad, at all), because I have no idea how to determine:

  • if my server is running smoothly
  • if the server is under stress, and why
  • what applications are the heaviest
  • if there is the possibility of installing more apps
  • when peaks of stress are happening and what is causing them

In general, I would like to understand the fundamentals of server monitoring: what are the most critical metrics and what do they mean? What parameters do I have to keep an eye on?

I installed Prometheus and Grafana, but then I realized I have absolutely no idea what to do next… Do you have any suggestions?

I thought about watching some video tutorials, but I would not really know how they would relate to YunoHost installations.

Please, if possible reply in this thread of the YunoHost forum, so that we can keep track of this useful information also for others in the future. 🌻

Once I will have learned the basics, I would be very happy to write some pointers about this in the documentation, or an essential YunoHost Monitoring tutorial.

YunoHost Forum · YunoHost Monitoring 101Hi everyone! I have been running a YunoHost server for ~5 years now, but there is one question I have never been able to reply to: how loaded is my server? 👀 I am a terrible administrator, I have no idea how to determine: if my server is running smoothly if the server is under stress, and why what applications are the heaviest if there is the possibility of installing more apps when peaks of stress are happening and what is causing them In general, I would like to understand the fundam...

🖥️ Understanding the Linux File System 🐧

If you're diving into the world of Linux, one of the most important concepts to understand is the Linux File System (LFS). The way Linux organizes and manages data on a disk is essential for navigating, managing files, and running your system smoothly. So let’s break down how the Linux File System works, its structure, and the key components! 🚀

Really looking forward to speaking at @DevOpsDaysLondon today. My talk is about #OpenSource culture and being a maintainer. The conference is apparently sold out—if you're around today or tomorrow, please don't hesitate to say hi. I'll be in my purple #Cerbos t-shirt. :) We can chat about computer things like #SystemAdministration, #SRE, #DevOps, #Authorization or whatever. I also like talking about #gastronomy so if you've got restaurant or wine opinions, I'm all ears. :D #DevOpsDays

"Day 2 Ops" Linux for Kubernetes and Container Workloads (froscon2024)

More than ten years ago, CoreOS released the first Container Optimised Linux. Flatcar Container Linux, CoreOS' spiritual successor, incorporates a decade of operational experience, and focuses as much
media.ccc.de/v/froscon2024-310 #ccc #SystemAdministration #froscon2024 #3103 #2024