• (disco)

    Reminds me how I once had a program kill the "System" (PID 0) due to a programming error...

    Shutting down post...

  • (disco)

    Paula won't work so I have to. :scream:

  • (disco)

    So all I would need to do to mess this up would be to name my process with something having "SERVER" in it and spawn/slay them quickly enough that there's a difference between the number of "SERVER" processes when it counts them and when it actually starts killing them? Nice.

  • (disco)

    Man, @Remy, sure as hell I didn't think I'd get Jackie Brown reference this morning and I could probably frown upon it should it happen, but man do I feel it's perfect for an evening!

    Thanks!

  • (disco)

    I worked on a project once that had to be rushed at a particular stage and several modules that needed to be done got washed up by the deadline. Things had to work according to whichever solution came first. While plenty of smart people were involved the rush meant doing whatever worked first without research into better approaches or simply not having the time to invest on better approaches. I sometimes think that smart people being rushed can be even more dangerous sometimes because we can find some of the wackiest shortcuts very quickly. Hardware was sometimes the cheapest possible with no software for the platform requiring a manual solution. The result was a lot of horrors some of which even persist today and are still being rectified today.

    Funnily enough something very similar to this had been lingering around for ages because there was no time to enumerate cameras properly in a real programming language and implement a threaded driver:

    for i in $(seq $(( 1 + `ps aux | grep -v grep | grep /opt/camera/driver | wc -l` )) `lsusb | grep "1234:4321" | wc -l`)
    do
      nohup /opt/camera/driver &
      sleep 1
    done
    

    This starts a driver daemon for each camera and runs in the background continually restarting a daemon whenever one crashes as an added bonus also allowing cameras to be added and removed as long as you were lucky enough the removing one crashed the driver, which it usually did in most cases with a segfault because of incomplete handling.

    A quick bit of bash came to the rescue so many times. Much of it has been improved and I had to replace far worse than this. Some of the rushed solutions without proper checking, etc did cause problems with unexpected input (especially empty variables). This bit was long scheduled to be replaced as well but still persists in production to my knowledge because writing proper drivers is hard and this approach at least works.

    Some of the worst parts were things such as exporting a variable whose name, assignment and value is another variable which turned out to be empty creating a lot of spam everywhere. Sleep after sleep doubled the time to do anything and created weird anomalies when unexpected delays occurred. One of the strangest things was stealing env variables as needed from other processes in proc that were expected to be started but in a different scope which caused a lot of confusion when I removed unnecessary processes and things broke in very strange ways. Yes, that is how the exports broke as well because the envs in proc are like A=B so it was just grepping for the one it wanted and transplanting to the args of export in the scripts that needed those envs. The greps were also sometimes unspecific and new envs would replace them with something arbitrary if they began or ended with a match or set a different env altogether. Sometimes these were credentials so it was borderline hacking. Could have been worse, at least it wasn't trying to steal args from the process list or something.

  • (disco)

    The part in this that annoys me is all of the pipes. Once your main program is in Python, you might as well do as much of it in Python as you can and only use the shell for the parts that Python can't do. That would mean the only shell command you need in all of that is the ps command. The rest is just text processing and a call to os.kill.

  • (disco) in reply to Dragnslcr

    Alternately, of course, write the while thing as a bash script, since the author was obviously more familiar with bash scripting than with Python, and then have a single shell-out call to call the script.

    Of course, the real question is why they didn't at least try this to replace all that code:

    subprocess.call(["killall", "SERVER"])

    Or maybe this, if the server was well-behaved enough to have an appropriate init script/systemd unit setup:

    subprocess.call(["service", "SERVER", "stop"])

  • (disco) in reply to Dragnslcr

    Strictly you don't even need ps, you could check /proc/*/cmdline instead.

  • (disco) in reply to PleegWat

    Yeah, I saw a couple posts about using /proc when I did a quick search, but I think one of them said it wasn't a good idea. I didn't care quite enough to dig into it any more than that.

  • (disco)

    @Remy, this word, "ineliganter": I haven't heard that before. Is that one of those degree words, I mean, is there an "ineligantest solution", for example?

    Either way, it's just not very mellifluous...but that's just me, I guess.

  • (disco) in reply to Dragnslcr

    Yeah, I saw a couple posts about using /proc when I did a quick search, but I think one of them said it wasn't a good idea. I didn't care quite enough to dig into it any more than that.

    proc is not always very portable. Not only between systems but between versions. There are other potential problems as well (file handles, parsing). Things use it anyway because it is convenient. The best thing is to use libraries. When you think you need a command line program I give this advice, look at that program's source. Often you can then make your own native module or library for it in your language and replace that upstream or figure out which libraries to use to make it in your own language. Often all those programs are doing is wrapping some libs to make them human readable ascii output. Often you'll only need to deal with a few dozen or hundred lines. People often overlook the power of opensource.

  • (disco)
    Melissa’s co-worker saw the inelegant solution, and said to **themselves**...

    So Melissa's coworker is some sort of hive mind?

  • (disco)

    Did they write the server too? If so, shouldn't they be sending it a special message to shut down?

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    @Remy, this word, "ineliganter": I haven't heard that before. Is that one of those degree words, I mean, is there an "ineligantest solution", for example?

    Either way, it's just not very mellifluous...but that's just me, I guess.

    The root word is "inelegant".

    Any adjective has a degree, but only those with two syllables or fewer have their own degree words formed, as a general rule, by adding "-er" and "-est" on. Longer than that and it's technically "more inelegant" and "most inelegant", unless trying for comic effect, as Remy seems to have done.

  • (disco) in reply to Matt_Westwood
    Matt_Westwood:
    The root word is "inelegant".

    Any adjective has a degree, but only those with two syllables or fewer have their own degree words formed, as a general rule, by adding "-er" and "-est" on. Longer than that and it's technically "more inelegant" and "most inelegant", unless trying for comic effect, as Remy seems to have done.

    I know the root word is "inelegant". I'm merely trying to find out if I can describe a :wtf: I found as, "This is the mostest ineleigantest WTF I've ever seen."

  • (disco) in reply to CoyneTheDup

    It's a perfectly cromulent word.

  • (disco)

    Wow.

    It is rare to see a function where the shell() or exec() part is almost as large as the rest of the code.

    I hope that the author was paid by the process. In that case he/she only needed one cent /process to be rich :smile:

  • (disco) in reply to Yazeran

    Still trying to work out if that's better or worse than the perl script i found in our codebase that contained

    system("rm " + $file);
    

Leave a comment on “Hero on the Half Shell”

Log In or post as a guest

Replying to comment #:

« Return to Article