3 ms·

So you can run `top` and see exactly what config the process is running under. If it was started with a config file, that file could’ve changed or disappeared s

• krick 4y ago
  Huh, this is a totally legit reason, but the solution is so horrible it shouldn't justify it. Yet I cannot come up with a "proper" way to handle this. Is there any?
  • humanistbot 4y ago
    A logging overlay that stores configs in a database and monitors each process. If you're testing at that scale, why would you limit yourself to what you can do with just top? To do it manually with flags and monitoring with top is very pets not cattle.
  • raldi 4y ago
    Put the config in a file and have a launcher program that turns it into flags, and then stop thinking about the flags.
  • closeparen 4y ago
    At my work, all services have a "debug" HTTP port with endpoints to, among other things, dump the running configuration. But I'll admit that's less general than flags, since it depends on the server processes being built from our standard frameworks. Also for us, we can't SSH onto hosts, and the scheduler that actually knows about args/pids/etc is fairly deep behind the curtain, but HTTP access is easy. But you could see different companies having different constraints.
  • silisili 4y ago
    That's a silly reason. At simplest, you could a) log the entire config at startup. or b) create a specific file with config used, if logging is too messy. or c) make an API to return the running config. or d) use envvars in a container, that you can just dump from 'env' at will. All of which would be cleaner and saner than browsing top.
• deleted 4y ago
  [deleted]