Error on starting the application Puppet in the Generic enablers Cosmos - bigdata

Good afternoon,
I have installed the Generic enablers Cosmos, following the manual BigData Analysis - Installation and Administration Guide. When I have come to 'Step 7: applying Puppet' and executed the commands, in the file puppet.err has appeared the following errors:
Error: Could not prefetch yumrepo provider ' inifilé: Section 'openvz-utils' is already defined, cannot re-defines in/etc/yum.repos.d/openvz.repo
Description: There is a conflict with the titles (indicated in bold type) of the file /etc/yum.repos.d/cosmos-openvz.repo and /etc/yum.repos.d/openvz.repo .
cat /etc/yum.repos.d/cosmos-openvz.repo
[openvz-utils]
...
[openvz-kernel-rhel6]
...
cat /etc/yum.repos.d/openvz.repo
[openvz-utils]
...
[openvz-kernel-rhel6]
...
[openvz-kernel-rhel6-testing]
...
Solution: I have realized a change in the titles of the file /etc/yum.repos.d/openvz.repo, example: [openvz-utils_1]
Error: Could not prefetch database_grant provider 'mysql': Execution of '/usr/bin/mysql mysql -Be describe user' returned 1: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
Description: in the folder /var/lib/mysql/ was not found the file mysql.sock.
Solution: I have installed mysql-server.x86_64:
yum install mysql-server.x86_64
At the end of the installations, I restarted the service:
/etc/init.d/mysqld stop
/etc/init.d/mysqld start
Error: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y list vzstats' returned 1: Error: Cannot retrieve repository metadata (repomd.xml) for repository: ambari. Please verify its path and try again
Description: This error appears in the machine of the Master node, this one is provoked by the configuration of the file [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/hieradata/my_environment/common.yaml, indicated in 'Step 6: Puppet configuration'. Concretely, the URL that use the IP: 130.206.81.65
Solution: in the file [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/hieradata /my_environment/common.yaml to change the line:
ambari::params::repo_url: 'http:// 130.206.81.65/cosmos/ambari/'
(without blank space)
for
ambari::params::repo_url: 'http:// public-repo-1.hortonworks.com/ambari/centos6/1.x/GA'
(without blank space)
Error: Could not update: Execution of '/usr/bin/yum -d 0 -e 0 -y list vzstats' returned 1: Error: Cannot retrieve repository metadata (repomd.xml) for repository: cosmos-libvirt. Please verify its path and try again
Description: it is the same problem as the previous error. The difficulty in this one is that I cannot modify the file [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/hieradata /my_environment/common.yaml in the line:
cosmos::params::cosmos_repo_deps_url: 'http:// 130.206.81.65/cosmos/rpms/cosmos-deps'
(without blank space)
Because it is line is used in several files:
cat /etc/yum.repos.d/cosmos-libvirt.repo
[cosmos-libvirt]
name=Cosmos LibVirt with OpenVZ - v1.0.5 - NO PolKIT
baseurl=http:// 130.206.81.65/cosmos/rpms/cosmos-deps//libvirt
gpgcheck=0
priority=10
enabled=1
cat /etc/yum.repos.d/cosmos-openvz.repo
[openvz-utils]
name=OpenVZ utilities
baseurl=http:// 130.206.81.65/cosmos/rpms/cosmos-deps//OpenVZ/openvz-utils
enabled=1
gpgcheck=0
priority=1
[openvz-kernel-rhel6]
name=OpenVZ RHEL6-based kernel
baseurl=http:// 130.206.81.65/cosmos/rpms/cosmos-deps//OpenVZ/openvz-kernel- > rhel6
enabled=1
gpgcheck=0
priority=1
It does not also allow to modify the file previous, in the moment to execute the command (indicated in 'Step 7: applying Puppet'):
puppet apply --debug --verbose \
--modulepath [COSMOS_TMP_PATH]/puppet/modules/:[COSMOS_TMP_PATH]/puppet/modules_third_party/ \
--environment my_environment --hiera_config [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/hiera.yaml \
--manifestdir [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/ [COSMOS_TMP_PATH]/puppet/modules/cosmos/manifests/site.pp \
> puppet.out 2> puppet.err
It will erase the modified.
Solution: https://github.com/telefonicaid/fiware-cosmos-platform/issues/4
I need help with the error:
Error: /Stage[main]/Ambari::Server::Config/Augeas[ambari-config-repoinfo]: Could not evaluate: Saving failed, see debug
Might they to throw me a hand with these last error?
Thank you in advance.
PD: Forgive for if it is written badly

Related

Setting repmgr witness node on Debian

I am trying to set up repmgr version 5 on Debian with PostgtrSql 11.
Seems like the documentation is more oriented towards centos/RHEL.
When I am trying to setup the witnes node to start the repmgr daemon, I get an error without any idea where to look for for seeing what is the cause of the error.
This is my repmgr.conf file:
node_id=3
node_name='PG-Node-Witness'
conninfo='host=10.97.7.140 user=repmgr dbname=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/11/main'
failover='automatic'
promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'
priority=60
monitor_interval_secs=2
connection_check_type='ping'
reconnect_attempts=6
reconnect_interval=8
primary_visibility_consensus=true
standby_disconnect_on_failover=true
repmgrd_service_start_command='sudo /etc/init.d/repmgrd start' #??????
repmgrd_service_stop_command='sudo //etc/init.d/repmgrd stop'#??????
service_start_command='sudo /usr/bin/systemctl start postgresql#11-main.service'
service_stop_command='sudo /usr/bin/systemctl stop postgresql#11-main.service'
service_restart_command='sudo /usr/bin/systemctl restart postgresql#11-main.service'
service_reload_command='sudo /usr/bin/systemctl relaod postgresql#11-main.service'
monitoring_history=yes
log_status_interval=60
register is OK:
repmgr -f /etc/repmgr.conf witness register -h 10.97.7.97
INFO: connecting to witness node "PG-Node-Witness" (ID: 3)
INFO: connecting to primary node
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
INFO: witness registration complete
NOTICE: witness node "PG-Node-Witness" (ID: 3) successfully registered
repmgr daemon dry-run OK too:
$repmgr -f /etc/repmgr.conf daemon start --dry-run
INFO: prerequisites for starting repmgrd met
DETAIL: following command would be executed:
sudo /usr/bin/systemctl start postg...#11-main.service
I setup /etc/default/repmgrd with:
REPMGRD_ENABLED=yes
and
REPMGRD_CONF="/etc/repmgr.conf"
But still get error when trying to run the daemon start:
$ repmgr -f /etc/repmgr.conf daemon start
I get:
NOTICE: executing: "sudo /etc/init.d/repmgrd start"
ERROR: repmgrd does not appear to have started after 15 seconds
HINT: use "repmgr service status" to confirm that repmgrd was successfully started
It is recommended to run repmgrd as a systemd service,
According to the docs (for debian) you may first need to configure /etc/default/repmgrd,
My configuration looks like this:
# default settings for repmgrd. This file is source by /bin/sh from
# /etc/init.d/repmgrd
# disable repmgrd by default so it won't get started upon installation
# valid values: yes/no
REPMGRD_ENABLED=yes
# configuration file (required)
REPMGRD_CONF="/etc/repmgr/12/repmgr.conf"
# additional options
REPMGRD_OPTS="--daemonize=false"
# user to run repmgrd as
REPMGRD_USER=postgres
# repmgrd binary
REPMGRD_BIN=/bin/repmgrd
# pid file
REPMGRD_PIDFILE=/var/run/repmgrd.pid
Secondly, I would revisit sudoers (visudo) in order to check whether the non-root user can execute sudo /etc/init.d/repmgrd start.
Further, the user who runs repmgr commands should be able to write logs depending on your configuration.
Apparently the correct command to start the repmgr daemon is:
repmgrd -f /etc/prepmgr.conf

brew install mariadb fails as system can not chown for auth_pam_tool

brew
brew install not work. this is the log.
% brew install mariadb
==> Downloading https://homebrew.bintray.com/bottles/mariadb-10.4.13.mojave.bottle.tar.gz
Already downloaded: /Users/shingo/Library/Caches/Homebrew/downloads/d56104142081a8230646ac3f245adf2414e515cd5f2aeeb0637614e9966e882c--mariadb-10.4.13.mojave.bottle.tar.gz
==> Pouring mariadb-10.4.13.mojave.bottle.tar.gz
==> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
Last 15 lines from /Users/shingo/Library/Logs/Homebrew/mariadb/post_install.01.mysql_install_db:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall mariadb`
==> Caveats
A "/etc/my.cnf" from another install may interfere with a Homebrew-built
server starting up correctly.
MySQL is configured to only allow connections from localhost by default
To start mariadb:
brew services start mariadb
Or, if you don't want/need a background service you can just run:
mysql.server start
==> Summary
🍺 /usr/local/Cellar/mariadb/10.4.13: 744 files, 169.9MB
I have tried to execute mysql_install_db
I have tried to execute mysql_install_db without brew. this is the log.
The brew displays only the last 15 lines, so I can't help it.
% /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
chown: /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool: Operation not permitted
Couldn't set an owner to '/usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool'.
It must be root, the PAM authentication plugin doesn't work otherwise..
Installing MariaDB/MySQL system tables in '/usr/local/var/mysql' ...
2020-05-29 22:13:03 0 [Note] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld (mysqld 10.4.13-MariaDB) starting as process 45440 ...
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: option '--innodb-large-prefix' requires an argument
2020-05-29 22:13:03 0 [ERROR] Parsing options for plugin 'InnoDB' failed.
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-29 22:13:03 0 [ERROR] Aborting
Installation of system tables failed! Examine the logs in
/usr/local/var/mysql for more information.
The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysqld --skip-grant-tables --general-log &
and use the command line tool /usr/local/Cellar/mariadb/10.4.13/bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
I noticed that the system can not chown for auth_pam_tool because Operation not permitted.
auth_pam_tool permission
this is my permission the directory.
% ls -l /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
-r-xr-xr-x 1 shingo staff 13608 5 10 04:28 /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
How to fix Operation not permitted?
Or is there any other reason why it cannot be installed?
Self resolved.
Anyway I gave it try start
Even though the installation was not successful, anyway I gave it try % mysql.server start.
A error log file was created.
A error log file was created by starting mysql server.
the error log shows:
2020-05-30 8:47:10 0 [Warning] InnoDB: innodb_open_files 300 should not be greater than the open_files_limit 256
2020-05-30 8:47:10 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-30 8:47:10 0 [ERROR] Aborting
An unknown value in the mysqlx-bind-address seems to be causing the error.
How to fix unknown variable
I found
the same error question. This question discussed a my.conf file.
~/.my.conf did not exist on my mac
/etc/my.conf did not exist on my mac
this question teach me the my.conf location.
Finally I found my.conf in /usr/local/etc/my.cnf.Certainly the settings for mysqlx-bind-address were written in my.conf.
So rm /usr/local/etc/my.cnf, then brew reinstall SUCCESS!.
The permission was irrelevant at all.
this work for me:
rm /opt/homebrew/etc/my.cnf

Source file not available anymore

I'm facing something new in my experience. An updated Yocto environment fails to build while fetching MariaDB:
WARNING: mariadb-5.5.64-r0 do_fetch: Failed to fetch URL https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz, attempting MIRRORS if available
ERROR: mariadb-5.5.64-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-BIEhFRRkoA"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/sysroots-uninative/x86_64-linux/usr/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/openembedded-core/scripts:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/bin/arm-openstlinux_eglfs-linux-gnueabi:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot/usr/bin/crossscripts:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/sbin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/sbin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/openembedded-core/bitbake/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/hosttools"; export HOME="/home/osboxes"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/downloads 'https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz' --progress=dot -v failed with exit code 8, output:
--2019-11-03 12:10:45-- https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz
Resolving downloads.mariadb.org (downloads.mariadb.org)... 116.203.207.31, 2a01:4f8:c2c:b04e::1
Connecting to downloads.mariadb.org (downloads.mariadb.org)|116.203.207.31|:443... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: http://ftp.hosteurope.de/mirror/mariadb.org//mariadb-5.5.64/source/mariadb-5.5.64.tar.gz [following]
--2019-11-03 12:10:46-- http://ftp.hosteurope.de/mirror/mariadb.org//mariadb-5.5.64/source/mariadb-5.5.64.tar.gz
Resolving ftp.hosteurope.de (ftp.hosteurope.de)... 80.237.136.138, 2a01:488:10:1::50ed:888a
Connecting to ftp.hosteurope.de (ftp.hosteurope.de)|80.237.136.138|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-11-03 12:10:46 ERROR 404: Not Found.
ERROR: mariadb-5.5.64-r0 do_fetch: Fetcher failure for URL: 'https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz'. Unable to fetch URL from any source.
ERROR: mariadb-5.5.64-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/temp/log.do_fetch.11382
ERROR: Task (/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/meta-openembedded/meta-oe/recipes-dbs/mysql/mariadb_5.5.64.bb:do_fetch) failed with exit code '1'
Now I see the URLs are hardcoded into: layers/meta-openembedded/meta-oe/recipes-dbs/mysql/mariadb.inc:
SUMMARY = "A robust, scalable, and reliable SQL server"
HOMEPAGE = "http://mariadb.org"
SECTION = "libs"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
SRC_URI = "https://downloads.mariadb.org/f/${BP}/source/${BP}.tar.gz \
file://fix-cmake-module-path.patch \
file://remove-bad-path.patch \
file://fix-mysqlclient-r-version.patch \
file://my.cnf \
file://mysqld.service \
file://install_db.service \
file://install_db \
file://mysql-systemd-start \
file://configure.cmake-fix-valgrind.patch \
file://fix-a-building-failure.patch \
file://change-cc-to-cc-version.patch \
file://0001-disable-ucontext-on-musl.patch \
"
Hence, I tried to retrieve the same file (mariadb-5.5.64.tar.gz) on the Internet and I found this:
https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz/from/http%3A//ftp.hosteurope.de/mirror/archive.mariadb.org/?serve
that seems very close to the one above, but the working one has another path as suffix.
I don't understand if they (the mariadb maintainers) changed the URLs or there is an error in the meta-openembedded recipe.
The maintainers of FOSS software, in this case the MariaDB Foundation, usually don't make promises that download URLS will remain unchanged. MariaDB uses a scheme to help downloaders find a nearby mirror site, and that's what you found.
Those mirrorfinders rely on stuff like http redirect operations. Browsers are good at handling those operations. Downloading code built into other programs may not be.
You may find it helpful to edit that URL in that recipe to point to the exact ftp file you need. It appears to be in this ftp folder.
http://ftp.hosteurope.de/mirror/archive.mariadb.org/mariadb-5.5.64/source/

Run downloaded SaltStack formula

I've downloaded the PHP formula by following the instructions here: https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
I've changed apache to php. In my salt config file (which I assume is /etc/salt/master), I've set file_roots like so:
file_roots:
base:
- /srv/salt
- /srv/formulas/php-formula
I don't know how I'm supposed to run it now. I've successfully run a salt state file by discovering that the documentation is incomplete, so I'd missed a step I wasn't aware of.
If I try to run the formula the same way I've been running the state, I just get errors.
salt '*' state.apply php-formula
salt-minion:
Data failed to compile:
----------
No matching sls found for 'php-formula' in env 'base'
ERROR: Minions returned with non-zero exit code
I've also tried: sudo salt '*' state.highstate, and it also has errors:
salt-minion:
----------
ID: states
Function: no.None
Result: False
Comment: No Top file or master_tops data matches found.
Changes:
Summary for salt-minion
------------
Succeeded: 0
Failed: 1
------------
Total states run: 1
Total run time: 0.000 ms
ERROR: Minions returned with non-zero exit code
You have to add a top.sls file to /srv/salt/, not just in /srv/pillar/. If you have a file called /srv/salt/php.sls, you have remove it, otherwise it will interfere with /srv/pillar/php.sls.
Contents of /srv/salt/top.sls:
base:
'*':
- php
This is kind of bizarre, because my previous test (which wasn't a formula) used /srv/salt/php.sls and /srv/pillar/top.sls. Now I'm using /srv/pillar/php.sls and /srv/salt/top.sls.

Empty DalekJS test case fails with error

I am trying to write my very first test case with DalekJS but it keeps failing on error:
Running tests
Running Browser: PhantomJS
OS: windows 7 32bit
Browser Version: 1.9.8
>> WARNING: done() not called before timeout!
RUNNING TEST - "_uid"
* 0 Assertions run
* TEST - "_uid" SUCCEEDED
0/0 assertions passed. Elapsed Time: 11.34 sec
I have just copy-pasted the example from dalekjs webpage:
module.export = {
'Page title is correct': function (test) {
test
.open('http://google.com')
.assert.title().is('Google', 'It has title')
.done();
}
};
I have even tried empty test function, but the error was the same.
dalek -v prits out:
DalekJS CLI Tools Version: 0.0.5
DalekJS local install: 0.0.9
Brought to you with love by: Sebastian Golasch (#asciidisco) 2013
Usage: dalek [test files] {OPTIONS}
Options:
--version, -v Shows the version of the dalek-cli & local dalek installation
--reporter, -r Reporter(s) you would like to invoke
--driver, -d Driver(s) you would like to invoke
--browser, -b Browser(s) you would like to invoke
--viewport Viewport dimensions you would like to invoke
--baseUrl, -u Base URL to append all .open()'s with if relative path is
given
--logLevel, -l Log level, controls the amount of information outputted to
the console (0 to 5)
--remote Starts a dalek host server for clients to connect to
--nocolors Disable colorized output in the console
--nosymbols Disable UTF-8 symbols in the console
--help, -h Show this message
Any help is appriciated.
Shimon
I can answer my question now. I had a typo in first line module.export instead of module.exports.
Sorry for bothering you with stupid question.
But still - could be the root cause printed (something like 'export' is undefined) instead of 'done() not called before timeout!'? :)

Resources