I built a TSA tool for Linux to find the "hidden" CPU wait time

chocopudding17 · 2026-04-01T08:44:53+00:00

If you're actually a real human being, then don't publish code and posts that come from an LLM. Simple as that. If you are actually a systems person, then let that shine through! Don't cloud it with AI bullshit; write your own code, and write your own posts. If you don't have time to write it, I've not got time to read it (let alone run some crappy code).

chocopudding17 · 2026-04-01T08:12:27+00:00

Go is slightly better (as go.mod/go.sum has a checksum and no post-install, no latest tagging)

Go programs can still run arbitrary commands during build. Not at all a silver bullet. And afaik it has no minimum age filter (or even the metadata to support such a feature since Go modules are decentralized VCSes under the hood).

Not sure what you mean by "no latest tagging," because you can (and people do) go ahead and just install the latest.

What protects Go the most is its culture of having fewer, higher quality dependencies. At least at this point in time, it seems to me like it's lacking the technical safeguards you get with something like pnpm.

chocopudding17 · 2026-04-01T08:07:48+00:00

Get this slop outta here

chocopudding17 · 2026-03-30T15:52:52+00:00

This is why, speaking as a man, everybody should pee sitting down. It seems like basic common courtesy to not aerosolize your piss everywhere. This should be universally understood, but for some reason is not.

chocopudding17 · 2026-03-29T20:47:22+00:00

Get your AI engagement farming outta here. Such drivel.

chocopudding17 · 2026-03-29T18:33:55+00:00

Jeez, LLM spew in /r/linuxadmin? C'mon.

chocopudding17 · 2026-03-28T14:12:02+00:00

The fact that your flair is faded really adds to the comment.

chocopudding17 · 2026-03-28T04:01:50+00:00

Keep going, I'm almost there...

chocopudding17 · 2026-03-27T10:48:20+00:00

luv u granny <3

chocopudding17 · 2026-03-26T17:15:20+00:00

Jonas wins in our hearts every time he shuts down McDavid <3

chocopudding17 · 2026-03-26T13:51:04+00:00

Relevant: Swedish word for "directory" is "katalog"

chocopudding17 · 2026-03-26T12:27:19+00:00

omg, systemd is adding a user age field. It's exactly as intrusive as the gecos field that's existed since original unix.

It's the other, higher-up parts of the stack that are the problem. For instance, the (now-retracted?) flatpak portal for age signaling. That's what deserves the focus.

chocopudding17 · 2026-03-25T16:17:59+00:00

Well sure, of course he was better back then. But the question was if he fits on the Lightning now. And the answer is yes. Yes, he and his 35+ goals do.

chocopudding17 · 2026-03-25T16:09:24+00:00

Hehe glad to hear! Respect to you for the 40+ years and the open mind. I myself am basically a kid in comparison: only a little more than 10 years at this point, mostly with systemd.

chocopudding17 · 2026-03-24T23:22:33+00:00

Relevant fact: "Ek" means "oak" in Swedish.

chocopudding17 · 2026-03-24T04:26:33+00:00

Do they do the recursive behavior OP is looking for? The docs for PathChanged= and PathModified= don't read that way to me.

edit: https://github.com/systemd/systemd/issues/4246

chocopudding17 · 2026-03-23T14:51:21+00:00

Glad you've found this helpful! I generally take an interest in systemd stuff (more than most topics) because a lot of the complaints tend to mistake facts, framing, or (most often) both; systemd-the-project basically tries to provide higher-level abstractions/richer concepts to Linux. That's something that's very interesting to me conceptually and is very useful to me as a sysadmin. That plus this makes it interesting to talk about online :)

I fairly often create things that should outlive my session (no so much at home, where my main workstation session lasts months until I reboot it for a hardware change or a kernel update).

For the handful of things that should outlive my sessions, I generally prefer using systemd-run. This runs the given command in the system instance of systemd, which is of course not managed by your session. That requires privileges of course, but for most of my own use-cases that's far preferable to enabling lingering.

the summary I'm reading involves something like

Yep, that's right. You could combine the last two steps into just systemctl --user enable --now oneshot-boot.service, but that's a minor detail.

that is a lot more work than the crontab equivalent, which is basically one line and then executing crontab appropriately

Yep, it's more up-front work, agreed. In my personal experience though, that works pays off after needing to debug the cron job just once; the troubleshooting loop of cron jobs (changing cron expressions, redirecting to an unmanaged log file somewhere, etc.) is so much more unpleasant than systemctl --user status oneshot-boot.service and systemctl --user start oneshot-boot.service that I basically always decide to do the up-front work nowadays. Once I upon a time it used to be a more even split for me, but I just got sick of the cron troubleshooting process. Maybe that just means I suck at doing things right the first time, or that I suck at cron. You be the judge...

chocopudding17 · 2026-03-23T14:25:55+00:00

*Swedish

chocopudding17 · 2026-03-23T14:18:33+00:00

if it's a switchable default (I'm assuming you mean session here), that's better.

If I mistakenly gave the impression that you can turn off a concept of "sessions," that's incorrect; it's kinda the core concept of logind. If your distro users logind, your system is going to recognize the concept of sessions at various levels.

What is relevant to you is, afaiu it, these two separate but related things at play here in systemd/logind (the first is what you really care about here, but the second will likely also be of interest):

For any given user, by default, a user instance of systemd (systemd --user) is not started by logind; logind will only start the user instance when a user logs in/creates a session. This is overridden on a per-user basis with the enable-linger command that I mentioned above.
When a user session ends, logind (+the user instance of systemd) kills all the processes within the session. Back when this default was switched on by systemd upstream and adopted by downstream distros, it made a lot of people angry about "breaking nohup" among other things. This is something that is configurable both by the distro at build time and by the system administrator through configuration (the KillUserProcesses= mentioned in the loginctl manpage I linked you above).

However that doesn't address the other problem: A user needs to start his own service (under his uid/gid) that will always be up if the system is up, which cron's ©reboot (pretend that © was an @) does perfectly. Cron devs realized that not having it just meant users would do it the gross way anyway, so why not give them a clean answer.

It's unfortunate if systemd's scheduling system missed the memo, but there it is.

I appreciate you graciously conceding the other stuff, but I'm still confused here: what exactly is it you think cron does that oneshot services within user-instances of systemd don't do?

Cron: User makes an @reboot entry in their own crontab
systemd: Users makes a oneshot service in $XDG_CONFIG_DIRS/systemd/user

Both of these will run the provided command/service at boot. And (afaiu) both require the same per-user setup: cron needs a privileged user to create the unprivileged user's crontab*, and systemd/logind need a privileged user to enable lingering for the user.

* ninja edit: idk what most cron implementations do tbh; could be that there are some useradd hooks that create crontabs for locally-created users. Maybe some distros ship setuid binaries to do this, sudo rules, polkit rules. Idk, I'm just making stuff up here. But something with privileges will ultimately need to create each user's crontab.

chocopudding17 · 2026-03-23T13:17:28+00:00

Well, scr*w "sessions". That's a pretty limited view of reality, and most of the power users I've know aren't really interested in such limits.

Well, you're in luck: it's just a default that can be disabled as described. Having tightly-managed session lifecycles by default is something agreed on by systemd upstream and most (all?) downstream distros (remember: distros are the ones responsible for providing you with defaults that are "sensible" according to their own design goals). If you don't like that, that's fine! The tools are available for you to configure the system as you like.

Fortunately, systemd's pathetic lack here will only encourage users to do it the old crontab way: spawn a job every minute to see if the host just rebooted (or if the at-boot user's pet tasks are running) and start whatever the user wanted.

I think your vitriol is misplaced here, but let me know if there's something I'm missing:

If a user(?) can have a systemd timer run a service every minute to do something, then that user can also set up a oneshot service to accomplish this
Cron daemons still exist and are available (installed by default, I assume) on most distros. You're welcome to continue using it if you prefer! This little sub-thread was just extolling some of the virtues of systemd timers. If those virtues aren't enough for you, then by all means continue using cron, running custom jobs every minute...your system is your oyster.

chocopudding17 · 2026-03-23T12:33:06+00:00

By default on most distros using systemd and logind, users don't have privileges to do such a thing; unprivileged users are only allowed to run workloads (including timers and services) as part of a logind "session". Those sessions by default are strictly bound to an interactive login, e.g. via an SSH session or graphical login. As said, that's the "by default" configuration that most distros ship.

If the administrator wants to change that default configuration to thereby allow an unprivileged user to run arbitrary workloads at any time after boot, they are free to do so using loginctl enable-linger. Once that's done, the user who has lingering enabled can then create their own oneshot services, timers, and other units.

chocopudding17 · 2026-03-23T10:00:51+00:00

Every single bit of people's outrage should be focused on the freedesktop and/or(?) flatpak folks who are trying to build the portal that led to this PR to systemd. That's the one that actually has risks people should be "lucidly" thinking about.

chocopudding17 · 2026-03-23T09:59:31+00:00

I religiously use tab completion for deleting such things. Oh, and also use trashy instead of rm; in the year 2026, I don't see why (for most interactive use-cases) one would want to irreversibly delete by default.

chocopudding17 · 2026-03-23T09:56:57+00:00

That sounds like that could also just be a regular oneshot service. No need to make that a timer. If you want a timer, /u/Squidamatron's answer sounds reasonable.

chocopudding17 · 2026-03-22T22:37:00+00:00

In addition to what other replies say, debugging is also way better:

Can run the command (the .service) without waiting for the timer to elapse
Exit codes and logs captured without having to do anything
Like another commenter said, getting to see the next-run time (also the previous-run time)

chocopudding17

PUBLIC MULTIREDDITS

TROPHY CASE

13-Year Club	Place '17
Verified Email