• PowerCrazy@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    I didn’t know any of this. Amazing. I usually just look at /proc/net/ for routes and bonding config etc.

    • Shadow@lemmy.ca
      link
      fedilink
      arrow-up
      0
      ·
      12 days ago

      If you delete a file that’s still open by the app, the link in proc will still exist and you can copy the file back out of proc.

      • RustySharp@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        12 days ago

        Does that not make them a hard link (pointing to a filesystem node) instead of a symlink (pointing to another filename)?

        • Shadow@lemmy.ca
          link
          fedilink
          arrow-up
          0
          ·
          12 days ago

          No, you can’t have a hard link cross filesystems and proc is its own fs type.

                • Shadow@lemmy.ca
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  11 days ago

                  It still is! If you try and boot a kernel with nothing in /dev, you won’t get most of the kernel boot messages since /dev/console doesn’t exist. You need a basic set of device nodes in /dev before udev is started.

                  If you’re going to rsync a system to new hardware and exclude /dev /proc /sys, it’s better to setup a new mount of your / to a different directory and sync off that, so you get the underlying stuff without the cruft.

              • SlurpingPus@lemmy.world
                link
                fedilink
                arrow-up
                0
                ·
                11 days ago

                These days there can be a dozen virtual filesystems doing various stuff. If you ever want to get quite baffled, install a terminal emulator on an Android phone (not Termux) and run mount.

    • redjard@reddthat.com
      link
      fedilink
      arrow-up
      0
      ·
      11 days ago

      Also known as zombie files. If you are unlucky they can take up all space on a drive, or even tmpfs (so your ram) and you can’t easily find them. At least until you end the right process or restart.
      Had that happen once and had to write my own script to trace it to the log of an open terminal emulator tab that had billions of lines.

  • pelya@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    12 days ago

    Do you know how to build portable executables?

    configure --prefix=/proc/self/pwd
    

    It even works in .so files and libtool.

      • pelya@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        11 days ago

        --prefix=$(pwd) is resolved at compile time. If you move your compiled .so files to a different directory, they stop working.

        • eleijeep@piefed.social
          link
          fedilink
          English
          arrow-up
          0
          ·
          11 days ago

          I see what you mean, very clever solution if a program is using the configure prefix by compiling it into the binary.

          That can’t be very common though is it? Usually the configure prefix is just used by make install to install the binaries into the prefix. If the compiled program needs to know where it is installed it can read argv[0].

          Have you seen this used somewhere?

          • pelya@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            11 days ago

            I am using this myself in Android app, where you can write files only inside /data/data/your.app.id/

            So naturally, if you want to publish a different app, your.app.id will be different, so you need to recompile all your Linux tools that you bundle inside your app.

            If you are not running your Linux tools on Android, you’d probably be better off using Docker or a chroot.

      • pelya@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        11 days ago

        The executable will search for .so files not inside predefined paths like /usr/lib but inside it’s current directory. You may theoretically put . as an argument to configure, but it converts that into an absolute path, snd libtool and linker fail when encountering relative paths inside shared library dependencies.

  • rumba@lemmy.zip
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    You used to be able to sudo cat /proc/kcore > /dev/dsp and listen to your ram

      • rumba@lemmy.zip
        link
        fedilink
        English
        arrow-up
        0
        ·
        9 days ago

        it rotated in between white noise, strobing sirens, digital corruption and silence.

      • rumba@lemmy.zip
        link
        fedilink
        English
        arrow-up
        0
        ·
        9 days ago

        It was before OSS was taken over by ALSA (and other things) for sound. OSS let you play loose and fast and was very forgiving. I just tried using pulseaudio to do it and barely got a burble of static out of it.

        • MonkeMischief@lemmy.today
          link
          fedilink
          arrow-up
          0
          ·
          8 days ago

          That is super rad. I wonder how hard it would be to replicate today.

          We could have a “RAMcore” subgenre. I wonder how running different processes affects the sound?

          Imagine if the German underground scene discovered RAM noises. . .damn, RAMmstein is already taken. XD

          All seriousness though…I now wanna know what my RAM sounds like. Lol

          • rumba@lemmy.zip
            link
            fedilink
            English
            arrow-up
            0
            ·
            8 days ago

            Stand up an old VM that still has OSS. I screwed around with current drivers and didn’t get anything cool sounding.

  • communism@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    11 days ago

    Julia Evans has a bunch of these really handy cheatsheets. I have several saved that I reference semi-regularly.

  • provectus@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    Did you know openBSD does not have this folder? I think the BSD’s do not use /proc. I do not know why though.

    • SlurpingPus@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      11 days ago

      That raises the question of how their ps, top, lsof and such work, since afaik in Linux they read from /proc.

      P.S. Looks like BSDs tug at the kernel via syscalls, namely sysctl and also the ‘kvm interface’ in the case of MacOS (not sure what ‘kvm’ thing is meant here). Seems vaguely reasonable, since procfs also queries the kernel for the info, so about the same resources would be used, perhaps even with the overhead of filesystem traversal and string-numbers conversion.

      • provectus@lemmy.ml
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 days ago

        I might be mistaken, but I think kvm stands for kernel virtual machine. Having no /proc, and interacting with sysctl instead sounds more secure, IMO.

  • lyralycan@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    12 days ago

    Great tips! Although if i may 🤓 just a little for the top right, it works because what you deleted isn’t the binary, it’s the pointer that points to the binary’s location. The data is still exactly as it was before “deletion”; the symlink is simply a copy of the original pointer’s info; and I’m speculating that the existence of any pointer prevents the system from recycling those addressed bits.

    • bruh@nord.pub
      link
      fedilink
      English
      arrow-up
      0
      ·
      12 days ago

      it merely deletes the inode from the directory instead of overwriting the actual data on the disk

  • jaybone@lemmy.zip
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    I’m aware of /proc but usually use lsof to find open fd’s for a process.

    Is one better than the other?

  • jaybone@lemmy.zip
    link
    fedilink
    English
    arrow-up
    0
    ·
    11 days ago

    I seem to recall in an Operating Systems class we wrote a kernel module and communicated with it through the proc interface?

    • white_nrdy@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      11 days ago

      I may have been through “SysFS” as well? In /sys/class you can setup char dev IO with a kernel module (and more). Very helpful for userspace <-> kernel communication (like DMA drivers for userspace applications)

      • jaybone@lemmy.zip
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 days ago

        Hmm yeah maybe it was /sys, it’s been so long I can’t remember.

        I seem to recall echoing into a file to set some value which we then checked the value of in the kernel module code. It was just a hello world type of thing for a college class.