erlang May 2014

erlang@lists.fedoraproject.org

1 participants
53 discussions

[Bug 1080382] New: tsung erlang lib directory is wrong on lib64
by Red Hat Bugzilla 10 Jul '14

10 Jul '14

https://bugzilla.redhat.com/show_bug.cgi?id=1080382 Bug ID: 1080382 Summary: tsung erlang lib directory is wrong on lib64 Product: Fedora Version: rawhide Component: tsung Assignee: cickumqt(a)gmail.com Reporter: kwizart(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: cickumqt(a)gmail.com, erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com Description of problem: The tsung erlang lib directory is wrong on lib64 when running the following command: tsung-recorder -p webdav start Version-Release number of selected component (if applicable): tsung-1.5.0-3.fc20.x86_64 How reproducible: always with tsung-recorder Steps to Reproduce: 1. tsung-recorder -p webdav start 2. 3. Actual results: Creating local Tsung directory /home/kwizart/.tsung Creating Tsung log directory /home/kwizart/.tsung/log Starting Tsung recorder on port 8090 $ {"init terminating in do_boot",{'cannot get bootfile','/usr/lib/erlang//lib/tsung_recorder-1.5.0/priv/tsung_recorder.boot'}} Expected results: don't know yet... Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1074288] New: erlang-rpm-macros installs macros files to /etc/rpm
by Red Hat Bugzilla 24 Jun '14

24 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1074288 Bug ID: 1074288 Summary: erlang-rpm-macros installs macros files to /etc/rpm Product: Fedora Version: rawhide Component: erlang-rpm-macros Assignee: lemenkov(a)gmail.com Reporter: ville.skytta(a)iki.fi QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, lemenkov(a)gmail.com Blocks: 1074261 The proper location for rpm macros files in rpm >= 4.11 is %{_rpmconfigdir}/macros.d, please move them there from /etc/rpm. If this package's specfile targets Fedora and EL >= 7 only, the location for macro files can be simply changed from /etc/rpm to %{_rpmconfigdir}/macros.d. If it is intended to work on EL 5 and/or 6 as well, you can define a macros dir for example as follows (all on one line) and install the macros to %{macrosdir}: %global macrosdir %(d=%{_rpmconfigdir}/macros.d; [ -d $d ] || d=%{_sysconfdir}/rpm; echo $d) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1074261 [Bug 1074261] macro files install dir tracker bug -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1059913] New: Race condition creating .erlang.cookie
by Red Hat Bugzilla 01 Jun '14

01 Jun '14

https://bugzilla.redhat.com/show_bug.cgi?id=1059913 Bug ID: 1059913 Summary: Race condition creating .erlang.cookie Product: Fedora Version: 20 Component: rabbitmq-server Assignee: hubert.plociniczak(a)gmail.com Reporter: jeckersb(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: erlang(a)lists.fedoraproject.org, hubert.plociniczak(a)gmail.com, lemenkov(a)gmail.com, skottler(a)redhat.com Description of problem: There is a race condition when starting rabbitmq-server for the first time. When the erlang runtime starts, it tries to read its cookie file (for rabbitmq, /var/lib/rabbitmq/.erlang.cookie) and if it doesn't already exist, it generates a new random cookie and creates the file. The following two lines from the rabbitmq-service.service unit file are involved: ExecStart=/usr/lib/rabbitmq/bin/rabbitmq-server ExecStartPost=/usr/lib/rabbitmq/bin/rabbitmqctl wait /var/run/rabbitmq/pid The rabbitmq-server command returns before the service is up. Therefor it is required to exec the additional rabbitmqctl wait in order to make sure the service starts all the way. However both of these are erlang programs, and they share the cookie startup code described previously. There is variance on the order of events and the eventual error. But generally what happens is: - ExecStart (rabbitmq-server) is run and exits. The erlang runtime is now booting in the background. - ExecStartPost (rabbitmqctl) is run. - rabbitmq-server determines the cookie file is not present, and generates a new cookie. - rabbitmqctl determines the cookie file is not present, and generates a new cookie. - rabbitmq-server writes the new cookie to disk and sets the file to read-only - rabbitmqctl tries to open the cookie file read/write in order to write its cookie, but errors with EACCESS because the file already exists and is read only. - The erlang runtime for rabbitmqctl crashes and the command returns with a non-successful exit code. - The entire service unit is marked as failed, and all of the processes are killed by systemd. Version-Release number of selected component (if applicable): rabbitmq-server-3.1.5-1.fc20.noarch erlang-R16B-03.1.fc20.x86_64 How reproducible: There is some variability since it's a race. I've provided my reproducer below that works 100% of the time for me, inside a F20 VM. In theory this behavior should still exist if starting the service from the cli instead of rebooting, but I can't reproduce it that way. Steps to Reproduce: 1. install rabbitmq-server 2. systemctl enable rabbitmq-server.service 3. reboot Actual results: Service fails to start, see attachment of journalctl output for error Expected results: Service starts cleanly Additional info: This is really an erlang bug, but the workaround for rabbit is simple (I'll post a patch in a followup). I'll run down the erlang bit separately but it will take longer, so it makes sense to apply the workaround here until erlang is fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

erlang May 2014