Coda is an advanced networked filesystem. It has been developed at CMU since 1987 by the systems group of M. Satyanarayanan in the SCS department.
Home Page: http://coda.cs.cmu.edu/
License: GNU General Public License v2.0
The name backup for the manpage (and I assume the binary as well) seems troublesome.
experienced with 6.9.6-2+ubuntu16.04 on Ubuntu 16.04
Ubuntu 16.10 with coda name yakkety has been released recently. It'd be nice if deb packages would be made available for it.
Don't think I've seen this one before. coda-7.0.5
Assertion failed: VV_Check(&HowMany, VV, 0) || IsWeaklyEqual(VV, VSG_MEMBERS), file "resfile.cc", line 184
***BackTrace***
/usr/sbin/codasrv(coda_assert+0x82)[0x80eaef2]
/usr/sbin/codasrv(_Z11FileResolveP11res_mgrpentP7ViceFidPP17ViceVersionVector+0x7d1)[0x80c2d31]
/usr/sbin/codasrv[0x807207a]
/usr/sbin/codasrv(FS_ViceResolve+0xad)[0x807243d]
/usr/sbin/codasrv(srv_ExecuteRequest+0x4e4)[0x8088934]
/usr/sbin/codasrv[0x8066c21]
/usr/lib/coda/liblwp.so.2(+0x5c54)[0xb76c6c54]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7759c8c]
linux-gate.so.1(__kernel_vsyscall+0x10)[0xb7759cb0]
/usr/lib/coda/liblwp.so.2(+0xa000)[0xb76cb000]
EXITING! Bye!
Every place we pack/unpack defines their own copy struct foo_in/foo_out and there are no helper functions to perform the packing or unpacking. Some ioctls are used in up to 6 places (f.i. GETVOLSTAT) and pack/unpack data without proper alignment.
We need proper pack/unpack functions, preferably in a common location maybe where the pioctl function is implemented (kerndep?).
On Ubuntu-xenial, python-notify was replaced by python-notify2 which is not quite compatible enough to be a drop-in replacement.
It'd be nice to have packages for Ubuntu 17.04/zesty.
$ sudo /usr/local/sbin/venus -d 5
Date: Fri 06/10/2016
02:41:57 Coda Venus, version 6.9.6�*���<��02:41:57 /var/lib/coda/LOG size is 46821888 bytes�*���<��02:41:57 /var/lib/coda/DATA size is 187277488 bytes�*���<��02:41:57 Loading RVM data�*���<��02:41:57 Last init was Wed Jun 1 03:57:26 2016�*���<��02:41:57 Last shutdown was dirty�*���<��02:41:57 Starting RealmDB scan�*���<��02:41:57 Found 2 realms�*���<��02:41:57 starting VDB scan�*���<��02:41:57 5 volume replicas�*���<��02:41:57 3 replicated volumes�*���<��02:41:57 5 CML entries allocated�*���<��02:41:57 0 CML entries on free-list�*���<��02:41:58 starting FSDB scan (41666, 1000000) (25, 75, 4)�*���<��02:41:58 13 cache files in table (987136 blocks)�*���<��02:41:58 41653 cache files on free-list�*���<��02:41:58 starting HDB scan�*���<��02:41:58 0 hdb entries in table�*���<��02:41:58 0 hdb entries on free-list�*���<��02:41:58 Kernel version ioctl failed.�*���<��02:41:58 Mounting root volume...�*���<���<��02:41:58 CHILD: mount system call failed. Killing parent.
�*���<��Getötet
Adding -init doesn't help:
$ sudo /usr/local/sbin/venus -d 5 -init
Date: Fri 06/10/2016
02:49:53 Coda Venus, version 6.9.6�*���<��02:49:53 /var/lib/coda/LOG size is 46819372 bytes�*���<��02:49:54 /var/lib/coda/DATA size is 187277488 bytes�*���<��02:49:54 Initializing RVM data...�*���<��02:49:55 ...done�*���<��02:49:55 Loading RVM data�*���<��02:49:55 Starting RealmDB scan�*���<��02:49:55 Found 1 realms�*���<��02:49:55 starting VDB scan�*���<��02:49:55 0 volume replicas�*���<��02:49:55 0 replicated volumes�*���<��02:49:55 0 CML entries allocated�*���<��02:49:55 0 CML entries on free-list�*���<��02:49:56 starting FSDB scan (41666, 1000000) (25, 75, 4)�*���<��02:49:56 0 cache files in table (0 blocks)�*���<��02:49:56 41666 cache files on free-list�*���<��02:50:03 starting HDB scan�*���<��02:50:03 0 hdb entries in table�*���<��02:50:03 0 hdb entries on free-list�*���<��02:50:04 Kernel version ioctl failed.�*���<��02:50:04 Mounting root volume...�*���<���<��02:50:04 CHILD: mount system call failed. Killing parent.
�*���<��Getötet
experienced with rvm-1.18-20-g03750fd (according to git describe)
Some units like coda-client.service sometimes require more than a minute to start (they seem to sometimes run -init, sometimes not, judging from the logs (documentation requested at #14)) and are then killed by systemd which might cause corruption leading to #33 and others.
experienced with 6.11.2-1+ubuntu16.10 on Ubuntu 16.10
Packages for Ubuntu 17.04 ship both an initd and a systemd script where the systemd scripts are masked. If only systemd ought to be supported, the initd scripts should be dropped and if both ought to be supported, they should come in separate packages, e.g. coda-server-initd and coda-server-systemd.
Please note that it's still extremely hard to setup coda without an up-to-date documentation (http://www.coda.cs.cmu.edu/ doesn't mention systemd and refers to Windows 95 (I'm not voting to update documentation for it, but rather for Linux systems, but it's a good time reference)).
When a server is restarted (or upgraded/downgraded) the existing logs are overwritten by the new process. I lost some valuable information in the logs when I downgraded from an experimental to a stable Coda server release.
Currently the systemd unit delegated to the initd unit which generally don't provide usable output because it gets lost in redirection or just logged to files without informing the user. systemctl status should reveal why the start failed and/or where to get the reason for the failure (log file, syslog, etc.).
This issue is especially annoying because codasrv doesn't have a verbose/foreground option (requested at #5) which could be used for debugging and simply returns 1 after a failure without giving any feedback which should never happen for any program.
It makes sense to migrate to systemd which should be discussed in a separate issue.
experienced with 6.9.6-2+ubuntu16.04 on Ubuntu 16.04
This issue is probably related to #13 but since its more specific I'll open an extra ticket.
I encountered some problems getting a server and a client to work with each other. While investigating this I found a spurious space character added to the server's hostname by createvol_rep (see screenshot below: what looks like an indentation is actually part of the given argument)
I've prepared two possible fixes (which might also be combined):
The second commit is a bit "more invasive" but I think it's a safe thing to do which also helps if there are other scripts injecting malformed arguments.
Running coda-client-setup seems to succeed, creating various things in /var/lib/coda. But it fails to update various paths in /usr/local/etc/coda/venus.conf, and this makes venus(8) - which defaults to /usr/coda - fail at startup.
This is under FreeBSD 12-CURRENT.
In file included from cml.multi.c:3:
./cml.h:1:2: error: unterminated conditional directive
#ifndef _CML_
^
Found this problem after the FreeBSD port was updated to 2.14.
sudo coda-client-setup richtercloud.de fails due to /usr/local/sbin/coda-client-setup: line 176: [: char-major-67-*: binary operator expected.
There's a thread on the mailing list which tries to figure out the reason for the issue and links bug reports about packaging in Redhat.
experienced with coda-6.9.9
There are quite a few cases where source and documentation have diverged, but I'm not sure where the latest version of the documentation is. ISTR we converted everything to Docbook XML at some point, but have only located CVS repos and checkouts with older Linuxdoc SGML documentation source.
Maybe more of a coda-packaging issue, but we should try to avoid restarting the coda-client when upgrading the package. When the restart fails it breaks the upgrade process and restarts will fail when RVM or the venus-kernel API has an incompatible change, or when some process is preventing us from unmounting /coda.
After installing coda-server Debian package the systemd unit fails to start. Running sudo codasrv -d in gdb reveals that a segmentation fault occurs:
$ sudo gdb codasrv
(...)
Reading symbols from codasrv...(no debugging symbols found)...done.
(gdb) set args -d
(gdb) run
Starting program: /usr/sbin/codasrv -d
Program received signal SIGSEGV, Segmentation fault.
__GI_____strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=<optimized out>, loc=0x7ffff6ac8420 <_nl_global_locale>)
at ../stdlib/strtol_l.c:293
293 ../stdlib/strtol_l.c: No such file or directory.
(gdb)
experienced with 6.9.7-2+ubuntu16.04 on Ubuntu 16.04
The Coda server creates /vice/srv/CRASH and normally the startserver script removes this file after the server cleanly exists. However systemd doesn't use the startserver script and so the CRASH file is left behind after shutdown. Because there is a pre-condition on startup that this file should not exist the server will not be restarted by systemd until the user manually removes /vice/srv/CRASH.
The Coda server process probably should remove the file right before it exists after a successful shutdown.
Hi,
I discovered Coda some years ago, at that time the project appeared to be semi-abandoned. Now I see there's some progress, this repo gets updates.
What is the current state of the project? Is Coda production-ready? If not, what are the main issues that should be solved? What core functionality is not working?
Also, I'd like to know who is maintaining the project and what are the plans for the future? Is there a roadmap?
Thanks!
Seems VASTRO related. We crashed when trying to copy a bitmap while copying a cachefile during repair. Why we have a bitmap to copy, I'm not sure because this was a CML_STORE operation so it couldn't have been a partially cache file. Either way we crashed because the recoverable bitmaps require a transaction.
CacheFile::Copy is called from only a few places.
fsobj::MakeShadow is called from
So basically we are sometimes called without a transaction, and sometimes with, but most cases we probably don't care, or even shouldn't have to care about partially cached files because except for cache recovery during startup all are in the file write paths or an extension thereof.
The /usr/sbin/coda-client-setup script which is provided by .deb package on Ubuntu 16.04 has the content
-e #!/bin/sh
set -e
echo "Starting \"dpkg-reconfigure coda-client\""
dpkg-reconfigure coda-client
which makes the script run, but causes a warning for the syntax error.
experienced with 6.9.9-1+ubuntu16.04
After transferring 7GB of data in approx 100K files venus crashes due to
00:02:39 fatal error -- Assertion failed: file "fso_cfscalls2.cc", line 268
00:02:39 RecovTerminate: clean shutdown
Assertion failed: 0, file "fso_cfscalls2.cc", line 268
***BackTrace***
/usr/sbin/venus(coda_assert+0x76)[0x56525a2bca66]
/usr/sbin/venus(_Z5chokePKciS0_z+0xc8)[0x56525a27b428]
/usr/sbin/venus(_ZN5fsobj7ReleaseEi+0x164)[0x56525a264764]
/usr/sbin/venus(_ZN5fsobj5CloseEij+0x24)[0x56525a2648a4]
/usr/sbin/venus(_ZN5vproc5closeEP11venus_cnodei+0x18b)[0x56525a29de2b]
/usr/sbin/venus(_ZN6worker4mainEv+0xbdd)[0x56525a24919d]
/usr/sbin/venus(_Z13VprocPreamblePv+0xbe)[0x56525a2990ae]
/usr/lib/coda/liblwp.so.2(+0x5d7c)[0x7f719d39bd7c]
/lib/x86_64-linux-gnu/libc.so.6(+0x357f0)[0x7f719c7587f0]
/lib/x86_64-linux-gnu/libc.so.6(sigsuspend+0x16)[0x7f719c758b26]
[0x7ffc3ed9ad00]
Sleeping forever. You may use gdb to attach to process 8098.
and the backtrace in gdb is
#0 0x00007f719c7f02d0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f719c7f023a in __sleep (seconds=0, seconds@entry=1) at ../sysdeps/posix/sleep.c:55
#2 0x000056525a2bcaf2 in coda_assert (pred=pred@entry=0x56525a2d3c70 "0", file=file@entry=0x56525a2c3e2d "fso_cfscalls2.cc", line=line@entry=268) at coda_assert.c:66
#3 0x000056525a27b428 in choke (file=file@entry=0x56525a2c3e2d "fso_cfscalls2.cc", line=line@entry=268, fmt=fmt@entry=0x56525a2c0978 "Assertion failed: file \"%s\", line %d\n") at venusutil.cc:208
#4 0x000056525a264764 in fsobj::Release (this=this@entry=0x9b38c810, writep=writep@entry=1) at fso_cfscalls2.cc:268
#5 0x000056525a2648a4 in fsobj::Close (this=0x9b38c810, writep=1, uid=<optimized out>) at fso_cfscalls2.cc:313
#6 0x000056525a29de2b in vproc::close (this=this@entry=0x56525b2dba80, cp=cp@entry=0x15175930, flags=3) at vproc_vfscalls.cc:264
#7 0x000056525a24919d in worker::main (this=0x56525b2dba80) at worker.cc:1205
#8 0x000056525a2990ae in VprocPreamble (arg=arg@entry=0x56525b2dbb08) at vproc.cc:152
#9 0x00007f719d39bd7c in _thread (sig=<optimized out>) at lwp_ucontext.c:91
#10 <signal handler called>
#11 0x00007f719c758b26 in __GI___sigsuspend (set=0x7ffc3ed9abb0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:30
#12 0x00007ffc3ed9ad00 in ?? ()
#13 0x00007ffc3ed9ad00 in ?? ()
#14 0x00007ffc3ed9ad01 in ?? ()
#15 0x00007ffc3ed9adee in ?? ()
#16 0x00007ffc3ed9ad00 in ?? ()
#17 0x00007ffc3ed9adee in ?? ()
#18 0x0000000000000000 in ?? ()
experienced with 6.11.2-1+ubuntu16.10 on Ubuntu 16.10
I git cloned 6.11.1 and followed the directions on the git site all the way through make install and everything went without error but venus would not init or run as I was trying to run venus-startup which no longer exists I've now discovered but still when I ran coda-client-setup defaul directories and files were not created so venus would not start. However, when I found the cyg-postinst.sh that gave me the clue to the directories and files and I used the Linux apropriate parts of that script to fix things and now the venus client works. Just a heads up you really need to update the docs and find out way make install did not finish the job.
my linux setup:
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.3
DISTRIB_CODENAME=rosa
DISTRIB_DESCRIPTION="Linux Mint 17.3 Rosa"
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.3
DISTRIB_CODENAME=rosa
DISTRIB_DESCRIPTION="Linux Mint 17.3 Rosa"
NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"
Large values for cacheblocks in venus.conf like 1000000000 or 500000000 cause Recov_InitRDS: rds_zap_heap failed (RVM_ENOT_MAPPED) during venus -init. No matter whether this is connected to the value or not the feedback should be improved explaining verbosely what the problem and possible fixes are. 10000000 works without problems.
experienced with 6.11.2-1+ubuntu16.10 on Ubuntu 16.10
experienced with 6.9.6-2+ubuntu16.04
When bootstrapping and building coda-7.1.0, rpc2's configure script is run during bootstrap and a configure check runs which looks for lwp. But lwp may not be built or installed yet, and in this case (on a fresh build on a system without lwp installed,) this configure check will fail as follows:
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for cp... cp -f
checking for x86_64-pc-linux-gnu-pkg-config... /usr/bin/x86_64-pc-linux-gnu-pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LWP... no
configure: error: Package requirements (lwp) were not met:
Package 'lwp', required by 'virtual:world', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LWP_CFLAGS
and LWP_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
configure: error: ./configure failed for lib-src/rpc2
Ideally, the configure script should understand that we are building a series of dependencies and lwp should be able to be found by rpc2 when it builds, so the bootstrap will 'just work'.
I noticed on repology.org that pkgsrc was out of date, and the version listed as current does not show up at http://coda.cs.cmu.edu/news.html but yet there is a tag on github (but not a release).
(Probably I have fallen off the list by entropy, or maybe I unsubscribed, but in any case I have not tried to run coda lately. I'll see about updating the pkgsrc package.)
After installing from source with ./bootstrap.sh && ./configure && make && make install a systemd unit /lib/systemd/system/coda-client.service is created with ExecStart=/usr/sbin/venus whereas venus has been installed into /usr/local/sbin.
I figured out that /lib/systemd/system/coda-client.service is created by sudo make install by wrapping it in checkinstall and viewing installed files in the package manager synaptic.
experienced with coda-6.9.9
After sudo rm -r /var/lib/coda/* && sudo touch /var/lib/coda/LOG /var/lib/coda/DATA && sudo apt-get install --reinstall coda-client causes systemd unit coda-client to fail with
Dez 01 22:09:49 richter-Lenovo-IdeaPad-Z500 venus[10053]: Date: Thu 12/01/2016
Dez 01 22:09:49 richter-Lenovo-IdeaPad-Z500 venus[10053]: 22:09:49 Coda Venus, version 6.10.0
Dez 01 22:09:49 richter-Lenovo-IdeaPad-Z500 venus[10053]: 22:09:49 /var/lib/coda/LOG size is 0 bytes
Dez 01 22:11:19 richter-Lenovo-IdeaPad-Z500 systemd[1]: coda-client.service: Start operation timed out. Terminating.
Dez 01 22:11:19 richter-Lenovo-IdeaPad-Z500 venus[10053]: 22:11:19 fatal error -- Recov_GetStatistics: rvm_statistics failed (200)
Dez 01 22:11:19 richter-Lenovo-IdeaPad-Z500 venus[10053]: 22:11:19 Fatal Signal (11); pid 10110 becoming a zombie...
Dez 01 22:11:19 richter-Lenovo-IdeaPad-Z500 venus[10053]: 22:11:19 You may use gdb to attach to 10110
Dez 01 22:11:19 richter-Lenovo-IdeaPad-Z500 systemd[1]: Failed to start Coda Cache Manager.
Dez 01 22:11:19 richter-Lenovo-IdeaPad-Z500 systemd[1]: coda-client.service: Unit entered failed state.
Dez 01 22:11:19 richter-Lenovo-IdeaPad-Z500 systemd[1]: coda-client.service: Failed with result 'timeout'.
The debugger backtrace after attaching gdb with gdb attach [pid] is
(gdb) bt
#0 0x00007fcc5ccbfb96 in __GI___sigsuspend (set=set@entry=0x7ffd9ba06410)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:30
#1 0x0000556d2b878e70 in SigChoke (sig=11) at sighand.cc:246
#2 <signal handler called>
#3 0x0000556d2b85024f in VenusPrint (fd=5, argc=argc@entry=1,
argv=argv@entry=0x7ffd9ba06af0) at venusutil.cc:269
#4 0x0000556d2b850449 in VenusPrint (fp=<optimized out>, argc=argc@entry=1,
argv=argv@entry=0x7ffd9ba06af0) at venusutil.cc:221
#5 0x0000556d2b850493 in DumpState () at venusutil.cc:475
#6 0x0000556d2b85069f in DumpState () at venusutil.cc:471
#7 choke (file=file@entry=0x556d2b89e1a1 "venusrecov.cc",
line=line@entry=561,
fmt=fmt@entry=0x556d2b89e3b8 "Recov_GetStatistics: rvm_statistics failed (%d)") at venusutil.cc:193
#8 0x0000556d2b84ccb0 in Recov_GetStatistics () at venusrecov.cc:561
#9 0x0000556d2b84cede in Recov_GetStatistics () at venusrecov.cc:566
#10 RecovFlush (Force=Force@entry=1) at venusrecov.cc:568
#11 0x0000556d2b878d9e in SigExit (sig=<optimized out>) at sighand.cc:258
#12 <signal handler called>
#13 0x00007fcc5cd81c70 in __read_nocancel ()
at ../sysdeps/unix/syscall-template.S:84
#14 0x00007fcc5df620d2 in read (__nbytes=2560, __buf=0x7ffd9ba07360,
__fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
---Type <return> to continue, or q <return> to quit---
#15 read_dev (dev=dev@entry=0x556d2bdd98a8, offset=<optimized out>, dest=dest@entry=0x7ffd9ba07360 "", length=length@entry=2560) at rvm_io.c:267
#16 0x00007fcc5df54eb7 in read_log_status (log=log@entry=0x556d2bdd9870, status_buf=status_buf@entry=0x0) at rvm_logstatus.c:690
#17 0x00007fcc5df5519f in open_log (dev_name=dev_name@entry=0x556d2bdd2930 "/var/lib/coda/LOG", log_ptr=log_ptr@entry=0x7ffd9ba07e60, status_buf=status_buf@entry=0x0,
rvm_options=rvm_options@entry=0x556d2bacdca0 <Recov_Options>) at rvm_logstatus.c:378
#18 0x00007fcc5df55394 in do_log_options (log_ptr=log_ptr@entry=0x7ffd9ba07ea0, rvm_options=rvm_options@entry=0x556d2bacdca0 <Recov_Options>) at rvm_logstatus.c:445
#19 0x00007fcc5df62cfe in do_rvm_options (rvm_options=rvm_options@entry=0x556d2bacdca0 <Recov_Options>) at rvm_status.c:127
#20 0x00007fcc5df514d3 in rvm_initialize (rvm_version=<optimized out>, rvm_version@entry=0x556d2b89e880 "RVM Interface Version 1.3 7 Mar 1994",
rvm_options=rvm_options@entry=0x556d2bacdca0 <Recov_Options>) at rvm_init.c:61
#21 0x0000556d2b84d8c0 in Recov_InitRVM () at venusrecov.cc:412
#22 RecovInit () at venusrecov.cc:241
#23 0x0000556d2b81c53b in main (argc=<optimized out>, argv=<optimized out>) at venus.cc:195
experienced with 6.10.0-1+ubuntu16.10 on Ubuntu 16.10
When a user previously accessed a directory and listed the content, it's possible to open the file with an external application (e.g. a video file with VLC media player). If the user doesn't have a valid token he_she only gets I/O error whereas it'd be more helpful to give a feedback like "Missing authentication token (did you run clog [user]@[realm])?".
experienced with 6.11.2-1+ubuntu16.10 on Ubuntu 16.10
Because the systemd unit files only test for existence of /vice/db/scm, but not actually check if the contents matches/vice/hostname, the updatesrv and auth2 master and slave daemons are always started simultaneously on every server which results in port conflicts, clog delays/timeouts, and /vice/db not getting synced correctly.
Simplest solution is probably to make the master daemons aware if they are running on the SCM and enter a noop loop if not. A slightly better approach is have single coda-update.service and coda-auth2.service files and let the daemons figure out if they should run as a master and/or slave.
When running df the ouput shows 4xcacheblocks. I tested it with the value specified in /etc/coda/venus.conf and with venus -c <n>. In both cases the same behaviour is seen.
I'm running kernel version 4.15.0-24-generic on Ubuntu 18.04.
Seen in master branch. I'm investigating if it's also present in previous commits/versions.
According to man codasrv there's no option to get verbose information logged to console (useful in conjunction when running the program in foreground mode/without forking/daemonizing).
experienced with 6.9.6-2+ubuntu16.04 on Ubuntu 16.04
/usr/sbin/startserver fails due to
Date: Tue 11/29/2016
02:23:46 Coda Vice, version 6.9.10 log started at Tue Nov 29 02:23:46 2016
02:23:46 Fatal: unable to map server-id 1 to host richtercloud.de,
as it is already assigned to host richtercloud.de
logged to /vice/srv/SrvLog. The message doesn't make a lot of sense for an average user and should contain information where parameters (server-id, etc.) are retrieved from and it would be nice if it'd contain hints how to fix that.
I don't overcome this message even after throwing away my setup and running vice-setup again (vice-setup might return successfully or not (as described in #23)). Specifying another server-id in vice-setup doesn't seem to help.
experienced with 6.10.0-1+ubuntu16.10 on Ubuntu 16.10
Following the coda howto I experience
Assertion failed: 0, file "srv.cc", line 307
***BackTrace***
codasrv(coda_assert+0x76)[0x4a53e6]
codasrv(_Z6zombiei+0xa9)[0x41cca9]
/lib/x86_64-linux-gnu/libc.so.6(+0x354a0)[0x7f61b13684a0]
codasrv(_ZN13recov_vol_log15ResetTransientsEj+0x21)[0x473371]
codasrv(_Z18VInitVolumePackageiii+0x3cf)[0x48a08f]
codasrv(main+0x8c1)[0x41b8b1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f61b1353830]
codasrv(_start+0x29)[0x41ca59]
EXITING! Bye!
in /vice/srv/SrvErr after creating a volume with sudo volutil create [partition path] [volume name] and a mountpoint with cfs mkmount [coda path] [volumen name].
ls -la [coda path] displays
lrw-r--r-- 1 richter nogroup 17 Jun 10 01:49 /coda/richtercloud.de/virtualbox-vms1 -> #virtualbox-vms1
experienced with 6.9.6-2+ubuntu16.04 on Ubuntu 16.04
After setting up a coda server and client connections on the server and client machine (2 machines in my LAN involved), I'm seeing the following behaviour:
/coda/[realm] with rsync the transfer rate is good (40MB/s) for some GB of data, then the transfer stalls so that the next file is only transferred after ~10minutes, sometimes stalls for hours, sometimes doesn't progress over night. venus on the server machine has12:43:36 fatal error -- Recov_LoadRDS: heap mismatch (0x50000000, d0488000) vs (0x50000000, 2d0488000)
Assertion failed: 0, file "venusrecov.cc", line 519
***BackTrace***
/usr/sbin/venus(coda_assert+0x76)[0x562f976a5a66]
/usr/sbin/venus(_Z5chokePKciS0_z+0xc8)[0x562f97664428]
/usr/sbin/venus(_Z9RecovInitv+0x335)[0x562f976617f5]
/usr/sbin/venus(main+0x332)[0x562f976305d2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fc1739433f1]
/usr/sbin/venus(_start+0x2a)[0x562f976328fa]
Sleeping forever. You may use gdb to attach to process 16261.
in the logs (the process has no backtrace in gdb).
venus randomly crashes on both machines due to[42079.451522] coda: venus_pioctl: Venus returns: -22 for (00000001.ffffffff.fffffffc.00000000)
[42083.097729] coda: Unexpected interruption.
[42083.097735] coda: venus_pioctl: Venus returns: -4 for (00000004.01000001.00000001.00000001)
(dmesg displays coda: Venus dead, not sending upcall)
venus on the server machine furthermore crashes due to13:21:29 fatal error -- fsobj::dir_Create: (.o6MxU0L3M1pnfonh4qr63fXobG5b2KtU,K04npr-Ldt841.Pfm1is, 2.7f000000.fffffffe.80f4f) Create failed 27!
13:21:30 RecovTerminate: dirty shutdown (1 uncommitted transactions)
Assertion failed: 0, file "fso_dir.cc", line 98
***BackTrace***
venus(coda_assert+0x76)[0x560019991a66]
venus(_Z5chokePKciS0_z+0xc8)[0x560019950428]
venus(_ZN5fsobj10dir_CreateEPKcP8VenusFid+0x12b)[0x56001993ae2b]
venus(_ZN5fsobj11LocalCreateEjPS_Pcjt+0x23)[0x5600199365e3]
venus(_ZN5fsobj18DisconnectedCreateEjjPPS_Pctii+0x291)[0x560019936951]
venus(_ZN5fsobj6CreateEPcPPS_jti+0x50)[0x560019936a00]
venus(_ZN5vproc6createEP11venus_cnodePcP10coda_vattriiS1_+0x2af)[0x56001997404f]
venus(_ZN6worker4mainEv+0x91d)[0x56001991dedd]
venus(_Z13VprocPreamblePv+0xbe)[0x56001996e0ae]
/usr/lib/coda/liblwp.so.2(+0x5d7c)[0x7f38193b2d7c]
/lib/x86_64-linux-gnu/libc.so.6(+0x357f0)[0x7f381876f7f0]
/lib/x86_64-linux-gnu/libc.so.6(sigsuspend+0x16)[0x7f381876fb26]
/usr/lib/coda/liblwp.so.2(lwp_makecontext+0x124)[0x7f38193b2f04]
which is not the same incident given the delay in time, but probably related. I/O operations with rsync on the server side then take for ever (> 30 minutes without progress without any noticable I/O in iotop).
[ W(13) : 0000 : 15:37:27 ] fsobj::TryToCover: vdb::Get(#@.Trash) failed (110)
[ W(13) : 0000 : 15:37:27 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.7>)
[ W(13) : 0000 : 15:37:27 ] Allowing access to stale status! (key = <1.ff000001.1.1>)
[ W(13) : 0000 : 15:37:27 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.8>)
[ W(13) : 0000 : 15:37:27 ] fsobj::TryToCover: vdb::Get(#@.Trash-1000) failed (110)
[ W(13) : 0000 : 15:37:27 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.8>)
[ W(13) : 0000 : 15:37:46 ] Allowing access to stale status! (key = <1.ff000001.1.1>)
[ W(13) : 0000 : 15:37:46 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.7>)
[ W(13) : 0000 : 15:37:46 ] fsobj::TryToCover: vdb::Get(#@.Trash) failed (110)
[ W(13) : 0000 : 15:37:46 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.7>)
[ W(13) : 0000 : 15:37:46 ] Allowing access to stale status! (key = <1.ff000001.1.1>)
[ W(13) : 0000 : 15:37:46 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.8>)
[ W(13) : 0000 : 15:37:46 ] fsobj::TryToCover: vdb::Get(#@.Trash-1000) failed (110)
[ W(13) : 0000 : 15:37:46 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.8>)
[ W(13) : 0000 : 15:37:47 ] Allowing access to stale status! (key = <1.ff000001.1.1>)
[ W(13) : 0000 : 15:37:47 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.7>)
[ W(13) : 0000 : 15:37:47 ] fsobj::TryToCover: vdb::Get(#@.Trash) failed (110)
[ W(13) : 0000 : 15:37:47 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.7>)
[ W(13) : 0000 : 15:37:47 ] Allowing access to stale status! (key = <1.ff000001.1.1>)
[ W(13) : 0000 : 15:37:47 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.8>)
[ W(13) : 0000 : 15:37:47 ] fsobj::TryToCover: vdb::Get(#@.Trash-1000) failed (110)
[ W(13) : 0000 : 15:37:47 ] Allowing access to stale status! (key = <1.ff000001.fffffffc.8>)
[ W(13) : 0000 : 15:37:47 ] Cachefile::SetLength 4096
in venus.log for some files only.
venus.log contains ***LWP (0x55dc733053c0): Select returns error: 4 the installation seems to be impossible to recover. I got into this state the last two times I wanted to get coda running and I'm now in it.These issue might be separate or connected, I'll separate them into different reports if you explain me a separation criteria - it's just very hard to understand what's going on if crashes happen due to non-verbose/difficult to understand assertion failures.
I noticed that venus is started with a delay of some seconds which is unrelated to the coda-client systemd unit because it's stopped which might interfere with a venus -init which sometimes restores responsiveness of the client after a reboot, but causes data loss.
experienced with 6.11.2-1+ubuntu16.10 on Ubuntu 16.10 amd64
Specifying a cacheblocks value of 100000000 repeatedly causes sudo venus -init to fail due to errors in the form of Fatal Signal (7); pid 1721 becoming a zombie... where gdb reveals the backtrace
#0 0x00007f69b6e70b26 in __GI___sigsuspend (set=set@entry=0x7ffd960172d0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:30
#1 0x0000556cf31e4d70 in SigChoke (sig=7) at sighand.cc:246
#2 <signal handler called>
#3 0x00007f69b8320c9e in split (size=<optimized out>, tid=0x556cf39cd3f8, err=0x7ffd960179f4) at rds_split.c:143
#4 0x00007f69b8320509 in rds_malloc (size=592, size@entry=568, tid=0x556cf39cd3f8, err=err@entry=0x7ffd960179f4) at rds_malloc.c:94
#5 0x0000556cf31fb8cf in rvmlib_malloc (size=size@entry=568, file=file@entry=0x556cf3202425 "fso1.cc", line=line@entry=94) at rvmlib.c:228
#6 0x0000556cf3192750 in fsobj::operator new (len=len@entry=568, fromwhere=fromwhere@entry=FROMHEAP) at fso1.cc:94
#7 0x0000556cf318ed59 in FSOInit () at fso0.cc:135
#8 0x0000556cf31885f0 in main (argc=<optimized out>, argv=<optimized out>) at venus.cc:213
experienced with 6.11.2-1+ubuntu16.10 on Ubuntu 16.10
On FreeBSD 12-CURRENT, trying to build it (with either make or gmake) fails like this:
gmake[4]: Entering directory '/usr/home/trasz/git/coda/coda-src/auth2'
/bin/sh ../../libtool --tag=CC --mode=link cc -g -O2 -I/usr/local/include -Wall -fno-exceptions -rdynamic -L/usr/local/lib -L/usr/local/lib -o au au.o libauser.la ../../coda-src/kerndep/libkerndep.la ../
../coda-src/util/libutil.la ../../lib-src/base/libbase.la -L/home/trasz/git/coda/lib-src/rpc2/rpc2-src -lrpc2 -lse -L/home/trasz/git/coda/lib-src/lwp/src -llwp -lkvm
libtool: link: cc -g -O2 -I/usr/local/include -Wall -fno-exceptions -rdynamic -o au au.o -L/usr/local/lib ./.libs/libauser.a ../../coda-src/kerndep/.libs/libkerndep.a ../../coda-src/util/.libs/libutil.a ../.
./lib-src/base/.libs/libbase.a -L/home/trasz/git/coda/lib-src/rpc2/rpc2-src -lrpc2 -lse -L/home/trasz/git/coda/lib-src/lwp/src -llwp -lkvm
./.libs/libauser.a(auth2.helper.o): In function `pack_struct_SecretToken':
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:19: undefined reference to `pack_bytes'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:21: undefined reference to `pack_integer'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:23: undefined reference to `pack_integer'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:25: undefined reference to `pack_integer'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:27: undefined reference to `pack_integer'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:29: undefined reference to `pack_integer'
./.libs/libauser.a(auth2.helper.o):/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:31: more undefined references to `pack_integer' follow
./.libs/libauser.a(auth2.helper.o): In function `pack_struct_SecretToken':
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:35: undefined reference to `pack_encryptionKey'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:37: undefined reference to `pack_integer'
./.libs/libauser.a(auth2.helper.o): In function `unpack_struct_SecretToken':
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:44: undefined reference to `unpack_bytes'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:46: undefined reference to `unpack_integer'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:48: undefined reference to `unpack_integer'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:50: undefined reference to `unpack_integer'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:52: undefined reference to `unpack_integer'
/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:54: undefined reference to `unpack_integer'
./.libs/libauser.a(auth2.helper.o):/usr/home/trasz/git/coda/coda-src/auth2/auth2.helper.c:56: more undefined references to `unpack_integer' follow
[etc, lots of other missing pack_ and unpack_ symbols]
When specifying the wrong name with volutil purge, there is both a volume is purge and volume is not purged message in the logs.
This happened with a file of size 64623045 Bytes. When playing a video as VASTRO ad the end codacon throws;
Fetch Earth.mov [63109] ( 20:45:15 )
fetching (Earth.mov) 0% (0Bs/18446744073709523397Bs) [64651264 - 64623045]
Note that the size of the chunk is supposly 18446744073709523397Bs. Maybe a negative number?
Apparently it's trying to access the nth block. In this case the 63109th block.
Entering characters at the Enter the uid of this user: causes them to be fail the UID setting with
Not a valid user-id (it needs to be > 0).
Owner must be a valid username/id, [entered characters] not found!
but the script proceeds. It's unclear what's the consequence of the invalid UID, i.e. whether the UID setting can be skipped or not. Anyway it's preferrable to enforce entering a UID in a loop until input is valid.
experienced with 6.9.6-2+ubuntu16.04 on Ubuntu 16.04
During copying files in the file manager nautilus I experienced the file transfer to never make any progress. codacon never shows any message, i.e. seems to hang right after start. dmesg contains
[ 1543.430037] ------------[ cut here ]------------
[ 1543.430092] kernel BUG at /build/linux-CFFAZ3/linux-4.10.0/mm/usercopy.c:75!
[ 1543.430152] invalid opcode: 0000 [#1] SMP
[ 1543.430191] Modules linked in: msr xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c xt_tcpudp bridge stp llc iptable_filter bbswitch(OE) binfmt_misc cdc_ether usbnet r8152 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media mii zfs(PO) zunicode(PO) zavl(PO) zcommon(PO) znvpair(PO) spl(O) nls_iso8859_1 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel cryptd intel_cstate intel_rapl_perf joydev input_leds serio_raw arc4 iwldvm mac80211 iwlwifi cfg80211 lpc_ich mei_me shpchp mei ideapad_laptop sparse_keymap mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core snd_hda_codec_hdmi configfs snd_hda_codec_conexant
[ 1543.430791] snd_hda_codec_generic iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device sunrpc snd_timer snd soundcore parport_pc ppdev lp parport coda ip_tables x_tables autofs4 btrfs xor raid6_pq hid_generic usbhid hid i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect psmouse sysimgblt ahci fb_sys_fops drm libahci wmi video fjes
[ 1543.431144] CPU: 3 PID: 2961 Comm: venus Tainted: P OE 4.10.0-24-generic #28-Ubuntu
[ 1543.431214] Hardware name: LENOVO IdeaPad U410 /Lenovo , BIOS 65CN90WW 09/25/2012
[ 1543.431282] task: ffff93be8bca4380 task.stack: ffffa652817fc000
[ 1543.431338] RIP: 0010:__check_object_size+0x77/0x1d7
[ 1543.431379] RSP: 0018:ffffa652817ffe08 EFLAGS: 00010286
[ 1543.431422] RAX: 0000000000000060 RBX: ffff93bd88530400 RCX: 0000000000000000
[ 1543.431477] RDX: 0000000000000000 RSI: ffff93beaf2cdc88 RDI: ffff93beaf2cdc88
[ 1543.431533] RBP: ffffa652817ffe28 R08: 0000000000068fae R09: 00000000000003ae
[ 1543.431588] R10: 0000000000000040 R11: ffffffffb9c487ed R12: 00000000000000c0
[ 1543.431641] R13: 0000000000000001 R14: ffff93bd885304c0 R15: 00000000000000c0
[ 1543.431698] FS: 00007f995f557b80(0000) GS:ffff93beaf2c0000(0000) knlGS:0000000000000000
[ 1543.431760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1543.431805] CR2: 00007f49a18bd000 CR3: 000000021032b000 CR4: 00000000001406e0
[ 1543.431861] Call Trace:
[ 1543.431893] coda_psdev_read+0x1a7/0x260 [coda]
[ 1543.431935] ? wake_up_q+0x80/0x80
[ 1543.431969] __vfs_read+0x18/0x40
[ 1543.431999] vfs_read+0x96/0x130
[ 1543.432029] SyS_read+0x55/0xc0
[ 1543.432060] entry_SYSCALL_64_fastpath+0x1e/0xad
[ 1543.432098] RIP: 0033:0x7f995dda0890
[ 1543.432130] RSP: 002b:00007ffd95278588 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 1543.432190] RAX: ffffffffffffffda RBX: 000000009b3dea88 RCX: 00007f995dda0890
[ 1543.432246] RDX: 0000000000002168 RSI: 0000563a31977730 RDI: 000000000000000a
[ 1543.432302] RBP: 0000000000000004 R08: 00007ffd952784b0 R09: 0000000000000000
[ 1543.432366] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 1543.432422] R13: 00000000000001a4 R14: 00000000000003e8 R15: 0000000059512a24
[ 1543.432480] Code: 48 0f 44 d1 48 c7 c6 b6 10 6a b9 48 c7 c1 e7 60 69 b9 48 0f 44 f1 4d 89 e1 49 89 c0 48 89 d9 48 c7 c7 00 db 69 b9 e8 58 e0 f6 ff <0f> 0b e8 92 ba fb ff 85 c0 75 73 48 89 df e8 d6 48 e3 ff 84 c0
[ 1543.432669] RIP: __check_object_size+0x77/0x1d7 RSP: ffffa652817ffe08
[ 1543.443761] ---[ end trace d0747e15526c0943 ]---
The issue is reproducible after each reboot.
experienced with 6.11.2-1+ubuntu16.10 on Ubuntu 17.04 with Linux 4.10.0-24-generic
I'm not sure which program mounts /coda, but venus (one of it's child processes to be precise) fails if the directory doesn't exist. It'd be nice if the directory would be created automatically (by venus or the child process) since there should be no disadvantage in that.
experienced with 6.9.6-2+ubuntu16.04 on Ubuntu 16.04
Strangely I still see this in the bash auto-completion of systemctl status, but not in the list of installed files in synaptic and can't find it in apt-file. Starting auth2 with root privileges works fine, but it'd be nice to have a dependency within the init manager.
codasrv isn't started neither.
experienced with 6.9.6-2+ubuntu16.04 on Ubuntu 16.04
The unlink systemcall works, but the rm command fails. this is probably caused by a failing access check before the actual unlink is called.
In lib-src/rpc2/rp2gen/Makefile.am there is a block of code from commit b7ca288 that goes thus:
# override any cross compilation target flags
CFLAGS=-Wall
LDFLAGS=
LIBS=
The problem is that my build system tries to build everything with position independent binaries (referred to often as building with PIE) to try and increase security. The clearing of CFLAGS in this manner is thus breaking my assertion that all binaries build are position independent.
I just would like to know what the problem is with having any cross compilation target flags in this build, as I would not want to build coda locally without keeping that in mind.
If vice-setup fails to create a root volume (before printing Now I'll try to create an initial root volume and following output), there's no feedback for the user except return code 1. Without checking the returncode the user might easily assume that vice-setup returned successfully. A message indicating the failure and explaining the reason (by forwarding a helpful error message or wrapping an unhelpful error message) would be very helpful.
experienced with 6.9.7-2+ubuntu16.04 on Ubuntu 16.04
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 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.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
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.