3 ms·

> > The real problem here is that it is impossible to diagnose or debug this situation. Simply to get this far I had to read the systemd source code (to find th

> > The real problem here is that it is impossible to diagnose or debug this situation. Simply to get this far I had to read the systemd source code (to find the code in timesyncd that printed this specific error message) and then search through 25,000 lines of strace output. And I still don't know what the problem is or how to fix it. > This seems to be really common practice in modern software development, and it sucks I have this discussion with the PM and CEO every now and then. It is impossible to give meaningful error messages for all errors. For known errors you can give a meaningful error message, but for errors not yet discovered it's more luck than anything if you give a meaningful error message. The best you can do it make the software robust so it'll work if a non critical subsystem/plugin fails. The next part of the discussion is usually them suggesting to just allocate time to figure most errors and write meaningful error messages for them. But the problem is that this isn't a mechanical system, but a system several orders of magnitude more complex, and even if we did spend multiple man-years doing it, the cost in terms of added complexity would be enough to get any management directly responsible fired. That said, I completely agree that developers should spend time supporting and running systems so they understand the impact of some of those decisions. Especially should it be expected that when you encounter errors that aren't bugs in the source code, you account for them.

alxlaz 8y ago
> It is impossible to give meaningful error messages for all errors. This problem was, however, largely non-existent back when most of the init code was shell code. It was easy to trace, easy to debug. (Edit: obviously, "easy" if you know sh and the idioms. They are, nonetheless, far easier than stracing stuff) It certainly had a lot of other problems (hence systemd's popularity) but debugging was definitely not one of them.
AnIdiotOnTheNet 8y ago
If you structure your software simply and make it easy to reason about what is going on, then any half decent error message should give enough information to at least start down the right path. But we don't get that in modern software. We get "Something went wrong :(".
- nomel 8y ago
  > If you structure your software simply and make it easy to reason about what is going on Complex problems are not easily made simple or easily reasoned about. Something like systemd (or any non trivial piece of linux) could never be made simple or, with your hands down in the guts of it, easily understood. Breaking systemd's functionality into a million separate pieces wouldn't make the complexity go away, it would necessarily increase it. I don't know what the solution is, but "making things simpler and easier to understand" is a bit hollow. Its problem space was never simple or easy to understand (unless you think systemd just runs some things at startup).
  - digi_owl 8y ago
    The trick is to have a environment where you can take the complex apart and examine each part in isolation, and then bring them together until you replicate the error. With older _nix setups that was fully possible because daemons were pretty much (i am likely to get dogpiled on this) a user process without a shell to send output to. With systemd on the other hand the state inside a systemd-managed unit, and the state outside of said "black box" may be wildly different. And to debug the person doing so have to attempt to maintain a massive mental image of state. Frankly the kernel may well be the closest approximation, and it may well be better instrumented at this point. Never mind that building a second kernel in userspace is not a kudos point.
Terr_ 8y ago
> It is impossible to give meaningful error messages for all errors. Not for end-users, no, because you're faced with a lot of future unknowns about who they are and what they were thinking of doing. For developers, on the other hand... IMO this has similarities to the "exceptions or return-type checking" debate. Certain architectural choices will have a strong impact on whether the inevitable runtime/production failures are mysterious or not.

alxlaz 8y ago

> It is impossible to give meaningful error messages for all errors. This problem was, however, largely non-existent back when most of the init code was shell code. It was easy to trace, easy to debug. (Edit: obviously, "easy" if you know sh and the idioms. They are, nonetheless, far easier than stracing stuff) It certainly had a lot of other problems (hence systemd's popularity) but debugging was definitely not one of them.

AnIdiotOnTheNet 8y ago

If you structure your software simply and make it easy to reason about what is going on, then any half decent error message should give enough information to at least start down the right path. But we don't get that in modern software. We get "Something went wrong :(".

nomel 8y ago
> If you structure your software simply and make it easy to reason about what is going on Complex problems are not easily made simple or easily reasoned about. Something like systemd (or any non trivial piece of linux) could never be made simple or, with your hands down in the guts of it, easily understood. Breaking systemd's functionality into a million separate pieces wouldn't make the complexity go away, it would necessarily increase it. I don't know what the solution is, but "making things simpler and easier to understand" is a bit hollow. Its problem space was never simple or easy to understand (unless you think systemd just runs some things at startup).
- digi_owl 8y ago
  The trick is to have a environment where you can take the complex apart and examine each part in isolation, and then bring them together until you replicate the error. With older _nix setups that was fully possible because daemons were pretty much (i am likely to get dogpiled on this) a user process without a shell to send output to. With systemd on the other hand the state inside a systemd-managed unit, and the state outside of said "black box" may be wildly different. And to debug the person doing so have to attempt to maintain a massive mental image of state. Frankly the kernel may well be the closest approximation, and it may well be better instrumented at this point. Never mind that building a second kernel in userspace is not a kudos point.

Terr_ 8y ago

> It is impossible to give meaningful error messages for all errors. Not for end-users, no, because you're faced with a lot of future unknowns about who they are and what they were thinking of doing. For developers, on the other hand... IMO this has similarities to the "exceptions or return-type checking" debate. Certain architectural choices will have a strong impact on whether the inevitable runtime/production failures are mysterious or not.