-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Added timestamping of log entries written to the log server #40
base: master
Are you sure you want to change the base?
Conversation
This gives us a better picture of the time elapsed between log entries. It also enables us to understand in what order things really occur (since they might get logged in the wrong order).
It's actually already mounted when the message is logged.
The reason is to get more predicable order of messages being printed in the log. It feels silly that the boot server goes on with its work before the vfs server has ACKnowledged that the mount has been done.
Alright. After having spent a bunch of unfruitful attempts at getting this working, I'm leaning towards the notion that this stuff has never worked. Which is strange, since I seem to remember it working. But it could very well be that I am mistaken, and the average quality (or lack thereof) of the code seems to indicate that... In chaos4ever/chaos-old@1aadeee, I noted that we seem to support starting |
The only real value that his PR adds is the timestamping of log entries. However, for whatever reason it doesn't work as intended; it always logs the same time... I don't fully know what the problem is here, but I feel like I want to resolve that before we merge this. |
Debugged this a bit further. The value that the |
Weird. The |
This PR is stale and should be rebased and fixed. |
(Title of this PR changed halfway. The original title was "//ramdisk/config/servers/boot/startup not found")
This is an attempt to work in a systematic way with trying to nail down this issue...
When booting up
chaos
now, I get this error:My conclusions thus far:
vfs_get_file_info
to try and step through the code. However, it's been an extremely unpleasant situation trying to get my hands dirty on this one. Because of chaos multiprocess/multi-threaded nature, stepping in the debugger will make things "jump around" very much, making it really really hard to understand what's going on.So I think:
gdb
to properly understand our process/thread model. Probably doable, amount of work unknown ORprintf
style debugging, i.e.log_print_formatted
. This is the approach I'm leaning towards and which I've tried to a certain points.Comments/suggestions/ideas from all of you are highly appreciated. This bug is really bothering me, and it's frustrating to not understand the code that we wrote 15 years ago... 😄