1. 56
  1. 6

    I just got the pun in the title.

    So if you get unixherp one too many times you become a Unix hater? Sounds about right.

    1. 5

      Can confirm this happens on openrc.

      1. 4

        Could you elaborate on where (Alpine, Gentoo, …) and how (commands) you tried that?

        Just to make reproduction a bit easier. :)

        1. 6

          Gentoo. I grabbed a service I had running (throttled), did # /etc/init.d/throttled stop; nice -n 19 /etc/init.d/throttled start, and observed that it was niced to 19.

          1. 2

            Thank you!

            Does this also happen if you use rc-service to start it?

            1. 1

              rc-service throttled stop; nice -n 19 rc-service throttled start Seems like it!

            2. 2

              Speaking from the heart, as someone who really needs to sit down and Fix a problematic chain of nested scripts and services someday… yikes.

        2. 3

          This sshd got started inside the “doubly niced” environment

          As for why “the processes didn’t notice and then undo the nice/ionice values”, think about it. Everyone assumes they’re going to get started at the usual baseline/default values. Nobody ever expects that they might get started down in the gutter and have to ratchet themselves back out of it. Why would they even think about that?

          These days, this should stand out as a red flag – all these little scripts should be idempotent.

          You shouldn’t write scripts where if you Ctrl-C them, and then re-run it, you’ll get these “doubling” effects.

          Otherwise if the machine goes down in the middle, or you Ctrl-C, you are left with something that’s very expensive to clean up correctly. Writing Idempotent scripts avoids that – and that’s something that’s possible with shell but not necessarily easy.

          As far as I can tell, idempotence captures all fhte benefits of being “declarative”. The script should specify the final state, not just a bunch of steps that start from some presumed state – which may or may not be the one you’re in!

          I guess there is not a lot of good documentation about this, but here is one resource I found: https://arslan.io/2019/07/03/how-to-write-idempotent-bash-scripts/

          Here’s another one: https://github.com/metaist/idempotent-bash

          1. 9

            I believe the “doubly niced” refers to “both ionice and nice”. There wasn’t any single thing being done twice by accident. The issue is with processes inheriting the settings due to Unix semantics.

            1. 4

              The problem is the API - it increments the nice value rather than setting it. From the man page:

              The nice() function shall add the value of incr to the nice value of the calling process.

              So the nice value did end up bigger than desired.

              1. 3

                That is an interesting quirk of nice()/renice, but in this case I believe they explicitly stated they originally set the nice value to 19, which is the maximum.

                1. 2

                  Thanks, you’re right! Took me a second reading…

              2. 1

                Ah yeah you could be right …

                But still the second quote talks about something related to idempotence. It talks about assuming you’re in a certain state, and then running a script, but you weren’t actually in that state. Idempotence addresses that problem. It basically means you will be in the same finishing state no matter what the starting state is. The state will be “fixed” rather than “mutated”.

                1. 3

                  Hmm, I still don’t think this is the case. The state being dealt with is entirely implicit, and the script in question doesn’t do anything with nice values at all, and yet still should be concerned about them.