Comments (15)
So, after thinking about it for a bit, I believe we should also print the full version number at startup. That way if we have a non-crashing bug, we can try to reproduce it with the same version of RethinkDB as the user. This is less important now, but will become more important as versions diverge more significantly.
from rethinkdb.
We already have rethinkdb --version
. We just need to print that by default.
from rethinkdb.
Update: it looks like rethinkdb --version
implemented in the PPA returns the string 'rethinkdb' . We should probably fix that :)
from rethinkdb.
Ideally, I think rethinkdb --version should print not only the version number, but also some details about the platform RethinkDB is installed on (Kernel v, FS, etc.).
from rethinkdb.
I agree that we should be able to print that information. I disagree about
putting it under --version. --version has a pretty well understood meaning
in the linux world and I don't think it includes this. It should be a
different command.
On Mon, Nov 12, 2012 at 9:34 AM, Alex Popescu [email protected]:
Ideally, I think rethinkdb --version should print not only the version
number, but also some details about the platform RethinkDB is installed on
(Kernel v, FS, etc.).—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-10296559.
from rethinkdb.
rethinkdb --arch
? or rethinkdb --platform
?
from rethinkdb.
I like platform best.
from rethinkdb.
The first part of this is done (we now print out version strings before backtraces, along with the compiler used to compile it).
It sounds like we also want to make RethinkDB collect some data about its environment at startup. Let's try to make a list of what we want to see before a backtrace:
- The version of RethinkDB
- The output of
uname -a
- The output of
df -T
Is there anything else?
from rethinkdb.
If journaling or other mount options matter, then df -T
won't show those-- the output of mount
will.
from rethinkdb.
cat /etc/issue
However, before we do this we should be aware that this ought to be portable. For example, /etc/issue
is meaningless in rpm (I think), so on that platform, we should call something else.
from rethinkdb.
We had some code at one point that collected disk information that might be
a good place to start.
On Monday, November 12, 2012, Michael Lucy wrote:
The first part of this is done (we now print out version strings before
backtraces, along with the compiler used to compile it).It sounds like we also want to make RethinkDB collect some data about its
environment at startup. Let's try to make a list of what we want to see
before a backtrace:
- The version of RethinkDB
- The output of uname -a
- The output of df -T
Is there anything else?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-10316645.
from rethinkdb.
Alright, I have a code review (#68) out for collecting runtime information. Here's what it looks like now when someone crashes:
Version: rethinkdb 1.2.6-25-ga5eba2-dirty (debug) (CLANG 3.0 (tags/RELEASE_30/final))
Runtime Data:
/etc/issue: Ubuntu 11.10 \n \l
/proc/version: Linux version 3.0.0-13-server (buildd@crested) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #22-Ubuntu SMP Wed Nov 2 15:09:08 UTC 2011
CWD: /home/ssd0/mlucy/rethinkdb/src
/proc/mounts: rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=32976644k,nr_inodes=8244161,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=13194172k,mode=755 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/disk/by-uuid/3945d61b-67ba-48e7-989c-c5049d4eeeea / ext4 rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
/dev/sdb1 /home/ssd0 xfs rw,noatime,attr2,delaylog,allocsize=512k,noquota 0 0
/dev/sdc1 /home/ssd1 xfs rw,noatime,attr2,delaylog,allocsize=512k,noquota 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
error: Error in extproc/pool.cc at line 215:
error: Error on worker process socket
error: Backtrace:
info: Server got SIGINT; shutting down...
info: Shutting down client connections...
error: Wed Nov 14 00:13:36 2012
1: lazy_backtrace_t::lazy_backtrace_t() at backtrace.cc:251
2: format_backtrace(bool) at backtrace.cc:198
3: report_fatal_error(char const*, int, char const*, ...) at errors.cc:76
4: extproc::pool_t::worker_t::on_error() at pool.cc:215
5: extproc::pool_t::worker_t::on_event(int) at pool.cc:207
6: non-virtual thunk to extproc::pool_t::worker_t::on_event(int) at pool.cc:208
7: linux_event_fd_watcher_t::on_event(int) at socket_stream.cc:71
8: non-virtual thunk to linux_event_fd_watcher_t::on_event(int) at socket_stream.cc:71
9: linux_event_watcher_t::on_event(int) at event_watcher.cc:73
10: non-virtual thunk to linux_event_watcher_t::on_event(int) at event_watcher.cc:85
11: epoll_event_queue_t::run() at epoll.cc:114
12: linux_thread_pool_t::start_thread(void*) at thread_pool.cc:136
13: +0x7e9a at 0x7f067f0dbe9a (/lib/x86_64-linux-gnu/libpthread.so.0)
14: clone+0x6d at 0x7f067ee0974d (/lib/x86_64-linux-gnu/libc.so.6)
error: Exiting.
trace/breakpoint trap (core dumped)
from rethinkdb.
- I think the value of printing mount info is very questionable. It turns the message into a wall of text, and I don't see what useful information we can extract out of it.
cat /etc/issue
isn't portable -- for example, we'll be adding rpm support soon and beyond. This needs to be abstracted (if it isn't already) so it can work on all systems or at least degrade to "can't determine the distro version".uname -a
is better than/proc/version
-- the former exists everywhere, whereas the latter does not.
from rethinkdb.
At first I was going to say that /proc/version is basically universal, but then I remembered that we're planning an OS X port, which means no /proc for us. (Actually, don't we use /proc in the stats collection, too?)
I'm hesitant to start forking processes while we're crashing. Why don't we just print the version number when we crash, like we do now, and fold this into the bug-report functionality?
Also, this sort of thing should really be encapsulated in a shell script rather than in C++ code.
Closing and merging into Issue #41, unless anybody objects.
from rethinkdb.
Makes sense to me.
from rethinkdb.
Related Issues (20)
- Rethinkdb Proxy
- Set a name to a proxy name HOT 3
- Add "Buffers" from /proc/meminfo in parse_meminfo_file to determine available memory
- download.rethinkdb.com is down, 502 Bad Gateway HOT 1
- Evaluate Profile-Guided Optimization (PGO) on RethinkDB
- error: to_string called on an uninitialized ip_address_t, addr_type: 0 compiling rethinkdb on Raspberry HOT 6
- RethinkDB not fully supported on Raspberry PI OS Bullseye (32/64 bit) HOT 10
- Reasonable to change hard-coded cluster size? HOT 5
- help bro my issue = warn: Problem when checking for new versions of RethinkDB: HTTP request to update.rethinkdb.com failed. HOT 1
- cluster connect/reconnect timeout HOT 1
- Installation fails in Kubuntu 23.10 HOT 4
- Generate web_assets.cc in a repeatable file order HOT 1
- Avoid full paths of coffeescript files in generation of web_assets.cc HOT 2
- Rethinkdb 2.4.4 release list HOT 11
- Support protobuf 25
- Return multiple changes feed
- Cache miss rate measurements HOT 4
- Something i forgot to had when having the default doc like so
- Connect rethinkdb directly from browser ? HOT 1
- Why exactly do rethinkDB add null characters to response / request JSON ? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rethinkdb.