| systemdlete | what is a deterministic way to test if a linux system is running systemd or absolutely is not? | 01:05 |
|---|---|---|
| systemdlete | I suggest something like "ps -o comm --no-headers -p1" | 01:06 |
| systemdlete | Some package maintainers need this to support non-systemd folks like us, here. | 01:06 |
| systemdlete | relying on testing for /usr/lib/systemd/system/. is NOT deterministic because our own non-systemd distro still has these files present | 01:07 |
| onefang | I would suggest running "systemd lete" and see if it fails, but that's just a joke. | 01:07 |
| systemdlete | But, onefang, I actually /like/ that joke. | 01:08 |
| onefang | B-) | 01:08 |
| fsmithred | check if init is really init or a symlink to some systemd shit | 01:10 |
| fsmithred | on debian: /sbin/init -> /lib/systemd/systemd | 01:15 |
| Xenguy | shitstemd | 01:16 |
| systemdlete | I looked for but maybe overlooked some file under /etc indicating which init system is being used. | 01:17 |
| systemdlete | Xenguy, please write it and package it for all distros | 01:17 |
| Alverstone | FYI I just grep runit or runsvdir :) | 01:22 |
| Alverstone | not terribly reliable | 01:22 |
| freem | check for fstab presence: if it's not around, it's systemd :D | 01:25 |
| freem | (not reliable, I know, some other inits may do the same silly thing of handling partitions, but those should probably be avoided as well as systemd anyway) | 01:25 |
| freem | `which systemd` as root may work, too, I suppose? | 01:26 |
| fsmithred | systemdlete, cat /proc/1/comm | 01:26 |
| fsmithred | I don't know if that works outside the debian world. | 01:27 |
| systemdlete | I think it would be best, if we are to suggest any solution, to provide a deterministic solution that should (in theory at least) work on all platforms. (Natch, Windoze will fail on ps...) | 01:27 |
| freem | on all platforms, including non POSIX ones? ambitious. | 01:28 |
| systemdlete | It's too bad that os-release does not have an init system field | 01:28 |
| onefang | fsmithred's first suggestion seems obvious and reliable to me. | 01:28 |
| systemdlete | onefang, actually, some of the scripts I've seen do exactly that. | 01:29 |
| systemdlete | but it does require some processing; one would hope for a "cleaner" and simpler solution I think | 01:29 |
| systemdlete | cat /proc/1/comm is a better way to get the same info | 01:30 |
| systemdlete | but /proc may not be mounted on all platforms, so one would have to test for that also | 01:30 |
| onefang | I said FIRST solution, checking for a symlink isn't hard. | 01:30 |
| fsmithred | stackexchange says cat /proc/1/exe but the output is ugly | 01:30 |
| onefang | fsmithred: check if init is really init or a symlink to some systemd shit | 01:30 |
| onefang | fsmithred: on debian: /sbin/init -> /lib/systemd/systemd | 01:30 |
| onefang | Is what he said. | 01:30 |
| fsmithred | oops. stackexchange says 'stat /proc/1/exe' which gives nice output. | 01:32 |
| fsmithred | Here's the reasoning they give: "The init process is always assigned PID 1. The /proc filesystem provides a way to obtain the path to an executable given a PID." | 01:33 |
| fsmithred | when would /proc not be mounted? | 01:34 |
| systemdlete | can we reliably count on /proc being mounted? | 01:34 |
| systemdlete | idk, solaris (illumos?) | 01:34 |
| freem | is systemd portable, now? | 01:34 |
| fsmithred | does solaris have systemd now? | 01:34 |
| systemdlete | no idea. What does it matter? | 01:34 |
| systemdlete | if it is not mounted, the test fails no matter what | 01:35 |
| systemdlete | so then you have to redirect stderr, etc | 01:35 |
| freem | well, you can already filter any non-linux kernels: they won't have systemd AFAIK | 01:35 |
| freem | then filter out muslc as IIRC systemd can't compile without GNU extensions | 01:35 |
| systemdlete | again, hoping for a universal, one-stop mechanism | 01:35 |
| systemdlete | *hoping* | 01:35 |
| systemdlete | (only hoping, ok?) | 01:36 |
| systemdlete | I think all of you have made some helpful suggestions | 01:36 |
| freem | systemd requires dbus... so there may be a way to ask dbus | 01:36 |
| freem | if no dbus, no systemd, and if dbus, ask dbus | 01:36 |
| systemdlete | what if a system doesn't have dbus; same problem as with /proc | 01:36 |
| freem | it's impossible | 01:36 |
| freem | systemd *requires* dbus | 01:36 |
| fsmithred | that wont work on my no-dbus builds | 01:36 |
| systemdlete | probably freem | 01:36 |
| onefang | You want a "isthishitstemd" command, and not happy with a two line shell solution you could stuff in a script called isitshitstemd? | 01:37 |
| freem | fsmithred: is it actually possible to run systemd as PID1 without dbus? | 01:37 |
| systemdlete | onefang, exactly *who* would be doing the stuffing? | 01:37 |
| fsmithred | freem, I've never tried it with debian | 01:37 |
| onefang | The people that need this function. | 01:37 |
| systemdlete | onefang, so all the package maintainers then? | 01:38 |
| freem | I thought systemd had a super hard dep on dbus because it needs it to communicate with daemons? | 01:38 |
| * systemdlete not so sure they will like that... | 01:38 | |
| freem | https://lists.freedesktop.org/archives/systemd-devel/2025-January/051066.html | 01:38 |
| systemdlete | freem, only with daemons? What about all the ghouls and apparitions it launches itself? | 01:38 |
| freem | so, it is actually possible... | 01:38 |
| freem | lol | 01:38 |
| systemdlete | lol | 01:38 |
| onefang | The point I'm making is you seem TOO focused on a simple command when a slightly more complex one will do the trick. | 01:39 |
| freem | "It uses a peer-to-peer dbus socket – i.e. not so much a 'dbus server' but a | 01:39 |
| freem | direct unix socket that happens to speak the dbus protocol. This is placed | 01:39 |
| freem | at /run/systemd/private and is restricted to root only " | 01:39 |
| freem | that seems a sane way to detect if systemd is running? | 01:39 |
| systemdlete | onefang, I am thinking about adoption, acceptance, etc. | 01:39 |
| onefang | What is so hard about checking a symlink? | 01:39 |
| freem | this is dated from 2025, so I guess it's fresh enough | 01:40 |
| fsmithred | why do package maintainers need to know this? | 01:40 |
| systemdlete | so far, I think fsmithred's suggestion of cat /proc/1/comm makes the most sense, with stderr directed to null and testing the output. That could be done ONCE at the top of a script (or a dotted-in script) and then tested as a variable | 01:40 |
| systemdlete | fsmithred, because many of them rely on systemd to launch various tools, say, postinst | 01:41 |
| systemdlete | s/many/some/ | 01:41 |
| systemdlete | so I am thinking thus: | 01:42 |
| systemdlete | IS_SYSTEMD=$(cat /proc/1/comm 2>/dev/null) | 01:42 |
| fsmithred | do any of those packages currently provide both init scripts and systemd service files? | 01:42 |
| freem | I wish people would stop run scripts for things that could be handled by splitting the package between: realprogram, realprogram-systemd, realprogram-other | 01:42 |
| systemdlete | then later on in the script | 01:42 |
| freem | would make things so much easier... for everyone. | 01:42 |
| systemdlete | test "$IS_SYSTEMD" == "systemd" (or maybe != as the case requires) | 01:43 |
| systemdlete | freem, I wish systemd wasn't. period. | 01:43 |
| freem | well, on this I am more mixed. And that does not removes the fact that having services starting automatically because you needed it to toy, is annoying as heck | 01:43 |
| freem | I have no love for sysVinit+rc.d as it was done in debian before, really. | 01:44 |
| freem | and the noise around systemd made me aware that alternatives exists :) | 01:44 |
| systemdlete | simplest of all is to get all distros to add a field to /etc/os-release for init type | 01:46 |
| freem | good luck with this | 01:46 |
| systemdlete | but that would require getting all the distros on board. | 01:46 |
| fsmithred | how do they know? | 01:46 |
| systemdlete | yeah, really freem | 01:46 |
| systemdlete | fsmithred, that was just me dreaming. Ignore... | 01:46 |
| fsmithred | and if you have more than one installed, os-release would need to edited at boot | 01:46 |
| freem | even if they were aware, many would refuse because "just use systemd and shut up" | 01:47 |
| systemdlete | freem, yep | 01:47 |
| systemdlete | sadly | 01:47 |
| systemdlete | it's all about the oligarchy today. | 01:47 |
| systemdlete | what they say is the TRUTH and no one may question it, ever | 01:47 |
| systemdlete | but this is getting a little OT | 01:47 |
| fsmithred | don't invent this tool. Some maintainers will use it to detect non-systemd and hose the system for you. | 01:47 |
| systemdlete | hahaha | 01:48 |
| systemdlete | they would, too! | 01:48 |
| fsmithred | nah, they just drop the init scripts from the package | 01:48 |
| systemdlete | I've seen that too--I was using bareos (nee bacula) for years and suddenly their packagers decided to stop including the init scripts | 01:49 |
| freem | I smiled at those people using systemd for embedded... considering the amount of RAM the shit uses, can this really be called "embedded"? | 01:49 |
| systemdlete | (but it was when they wrecked my backup system completely that I was done with them. restic all the way now...) | 01:49 |
| systemdlete | sure it can | 01:50 |
| systemdlete | the root of the word "embedded" is "bed," right? so having all that crap running eating up the system should slow it down to where it almost seems to be asleep | 01:50 |
| freem | nice one | 01:50 |
| * systemdlete really reaching there... | 01:50 | |
| systemdlete | thx | 01:51 |
| freem | I should join embedded world soon | 01:51 |
| plasma41 | If systemdlete returns, please let them know that '[ -d /run/systemd/system ]' is, as far as I'm aware, a reliable check for a running systemd. | 09:27 |
| plasma41 | As an example, I used this exact check this week in my patchset submission to the snapper package: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=7;bug=976888;filename=v2-1007-Make-cronjobs-defer-to-systemd-timers.patch;msg=22 | 09:28 |
| Alverstone | Using btrfs with zlib:9 compression has significantly improved performance over ext4 in my virtual machines, due to fewer I/O on quite slow external disks. | 13:06 |
| eyalroz | An interesting discussion on HackerNews regarding a NixOS-like, systemd-free distribution: | 14:49 |
| eyalroz | https://news.ycombinator.com/item?id=42884727 | 14:49 |
| eyalroz | One popular comment is "Can anybody explain to me again why systemd is so bad ?"... | 14:49 |
| n4dir | i sure can't remember anymore why i decided against it | 14:50 |
| Alverstone | what's so complex? i need an init system, systemd isn't an init system, period | 14:51 |
| eyalroz | Since the initial debates about this last decade, is there a more up-to-date web page or article one could direct users to, which considers how systemd has changed over the years, in the arguments against it? | 15:11 |
| eyalroz | Anyway, @Alverstone, I made the argument that it's been like "Stone Soup", if you know that folk tale; with the init system replacement being the stone put in the pot. | 15:12 |
| djph | except that one was about community coming together and making something better | 15:26 |
| al1r4d | n4dir, me too | 15:41 |
| freem | <n4dir> i sure can't remember anymore why i decided against it | 15:45 |
| freem | Memory usage is *huge*. You need to learn stuff that is only useable for systemd. Critical network IT flaws in PID1. Can not compile (could not, at least, for long) with a standard C library. Lack of clear goals lead to bloat and complexity and bugs, in PID1. | 15:45 |
| freem | Probably one of those :) | 15:46 |
| gnarface | this is not really a support topic | 15:47 |
| gnarface | eyalroz: save it for #devuan-offtopic | 15:47 |
| eyalroz | gnarface: Oh, sorry. I actually forgot that channel exists... | 16:20 |
| NICAD | Anyone here running a hybrid Desktop with integrated graphics on the Mobo and a separate Radeon card? | 22:19 |
| NICAD | Is there any way to force Xorg to use my Radeon card instead of the integrated Matrox card on my Motherboard? | 22:27 |
| debdog | elaborate! laptop? | 22:31 |
| Alverstone | iirc xorg.conf allows choosing video card, I'd check arch wiki maybe for details | 22:33 |
| NICAD | No. A desktop computer. The motherboard has an integrated graphics chipset, but I want to use the separate Radeon card that I've installed. | 22:34 |
| NICAD | Using Devuan here. | 22:34 |
| NICAD | The Kernel and drivers all see the Radeon card just fine. No errors. But for some reason Xorg still keeps defaulting to the Integrated graphics. | 22:35 |
| NICAD | The Radeon card has a DVI-I connector, while the integrated Matrox one just uses a VGA. | 22:36 |
| Alverstone | https://bbs.archlinux.org/viewtopic.php?id=243402 | 22:52 |
| Alverstone | The logic should be the same | 22:52 |
| fsmithred | NICAD, doesn't your motherboard let you change the order of the vid cards? | 22:57 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!