Logstash 6.7.0 fails to start with an error “Error: Permission denied - Permission denied” on macOS Mojave (10.14.4) - macos

Recently upgraded Logstash (which was installed via Homebrew) on macOS Mojave (10.14.4) to version 6.7.0 and things are not working as expected. When I try to run it manually via the command line—for local development purposes—I consistently get this error:
Error: Permission denied - Permission denied
Exception: Errno::EACCES
Stack: org/jruby/RubyFile.java:1263:in `utime'
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/fileutils.rb:1133:in `block in touch'
What’s maddening is when the same exact Logstash config files are used on the RedHat 7 production server where I have Logstash 6.7.0 installed as system service—via the official Elastic repos—everything works as expected.
My input config file looks like this:
input {
file {
path => "/opt/logstash/coolapp/access_log*"
exclude => "*.gz"
start_position => "beginning"
sincedb_path => "/dev/null"
close_older => "1 hour"
stat_interval => "1 second"
discover_interval => 15
This stuff is fairly simple as far as a config goes and all my settings match valid/accepted settings according to the official Logstash reference manual. But if I comment out the sincedb_path => "/dev/null" line, my Logstash setup on macOS works as expected.
What the heck is happening to cause this issue? I mean I can be aware of commenting out sincedb_path => "/dev/null" when I do local development work, but still… This is really annoying.

Okay, I figured this out… In a way. The issue is obliquely referred to in the error line:
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/fileutils.rb:1133:in `block in touch'
And the only temporary solution I have found is to comment out this line in my config:
sincedb_path => "/dev/null"
It seems that the production server I have running Logstash is using JRuby version 2.5.x and my local macOS version installed via Homebrew is using jRuby version 2.4.x. And apparently fileutils.rb in JRuby 2.4.x handles touch in cases for non-existent devices (such as /dev/null) differently than JRuby 2.5.x. And thus, Logstash fails on my macOS development setup.
So it seems this was all a Homebrew (or macOS?) issue rather than a Logstash issue.


Metoer not running

I did the following:
meteor create simple-todos
cd simple-todos
meteor --port 3030
[[[[[ ~/simple-todos ]]]]]
=> Started proxy.
=> Started MongoDB.
=> Started your app.
=> App running at: http://localhost:3030/
But my browser at localhost:3030 doesn't show anything. Other than:
Any help would be super!
I'm on a Mac. Using meteor (The current version)
I experience the same problem when running just the meteor command alone with no arguments.
I just noticed that my hostname is incorrect (name of a family member's ipad) I switched to a new hostname using the hostname command and set it to a new name (not my original) could this have something to do with issue?
It was a problem with my etc/hosts file (typo). If Vijay wants to post an answer I'll delete this and accept that.

rails s doesn't start server, no error messages

I haven't been able to find previous answered questions on this, unless I'm missing one. Anyways, when I try starting a rails server:
vagrant [accounts]> rails s
=> Booting WEBrick
=> Rails 4.2.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
[2015-06-06 02:38:50] INFO WEBrick 1.3.1
[2015-06-06 02:38:50] INFO ruby 2.2.2 (2015-04-13) [i686-linux]
[2015-06-06 02:38:50] INFO WEBrick::HTTPServer#start: pid=23016 port=3000
But that's all I ever get, no error messages or anything. Of course localhost:3000 produces 'no data received'
As you can see I'm using Ruby 2.2.2 and Rails 4.2.1
I'm in the root for the app, have tried updating bin.
I'm using the sqlite3 gem, I've created and migrated the db.
I am convinced it has nothing to do with this particular rails app because I've gone back and tried to open old projects that are now having the same problem. Recently I've upgraded from Ubuntu 12.04 to 14.04 on my vm. I've also recently upgraded ruby (I manage with rvm) and rails. I've also recently put some stuff on heroku. All of this has messed with $PATH (I'm not sure if this is related, I'm pretty new to all this stuff). Just wanted to detail everything I could think of that might have an effect.
I ran into the following problem recently, could this be your issue also?
If so try
rails s -b
3.3 Default Host for rails server Due to a change in Rack, rails server now listens on localhost instead of by default. This
should have minimal impact on the standard development workflow as
both and http://localhost:3000 will continue to
work as before on your own machine.
However, with this change you will no longer be able to access the
Rails server from a different machine, for example if your development
environment is in a virtual machine and you would like to access it
from the host machine. In such cases, please start the server with
rails server -b to restore the old behavior.
If you do this, be sure to configure your firewall properly such that
only trusted machines on your network can access your development
See the release notes here for the details.

The postfix module does not support the Debian family of operating systems

I have a vagrant and virtual box configuration and I tried installing postfix using puphet but I can't proceed because I always encounter this error when I run vagrant up or vagrant provision
Info: Loading facts in /etc/puppet/modules/rabbitmq/lib/facter/rabbitmq_erlang_cookie.rb
Warning: Could not retrieve fact fqdn
Error: The postfix module does not support the Debian family of operating systems. on node teaser-site-mgr
Error: The postfix module does not support the Debian family of operating systems. on node teaser-site-mgr
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
FACTER_ssh_username='vagrant' puppet apply --verbose --hiera_config /vagrant/puphpet/puppet/hiera.yaml --parser future --manifestdir /tmp/vagrant-puppet/manifests --detailed-exitcodes /tmp/vagrant-puppet/manifests/manifest.pp || [ $? -eq 2 ]
Stdout from the command:
and in my manifest.pp
class {'postfix':
remove_sendmail => false,
myorigin => undef,
relayhost => undef,
relayhost_port => undef,
I also added this mod in Puppetfile
mod 'postfix', :git => 'https://github.com/Aethylred/puppet-postfix'
Please help anyone m(_ _)m
#felix-frank --parser future is def. required by PuPHPet. Please don't remove this.
#inferno, the issue is you're trying to use this puppet-postfix module in a Debian OS, when it clearly states it does not support Debian.
Might I suggest https://github.com/example42/puppet-postfix ?
It seems that the error(s) I encountered is also somehow my fault.
Its because the puppet version now in my vagrant is 3.5.x (i created the config months ago) and i didn't noticed that the puphpet.com config has been also updated
and also the required puppet version is just 3.4.x
So when I run vagrant provision, the puppet version is updated to latest version which is 3.5.x (because of outdated puphpet config) thats why I always encounter the error (and sometimes syntax error)
im just wondering why puppet version 3.0 to 3.5 is now unsupported (but still puphpet.com is using it for vagrant) http://docs.puppetlabs.com/release_notes/
But anyways, thank you very much for your help guys :) I won't notice my mistake without all of your help m(_ _)m

TinyTDS Undefined symbol dbsetluser

I've been struggling for the last couple of days with this issue and I'm out of ideas. I am working on a somewhat out of date application, in which I now need to add support for SQL Server. I have managed to get it to work locally (Ubuntu 12.04), but I am running into the following error when trying to reproduce it on Rackspace on a Ubuntu 8.04 instance:
irb > require 'rubygems'
irb > require 'tiny_tds'
irb > TinyTds::Client.new(:host => 'X.X.X.X', :user name => 'xxx', :password => 'xxx')
irb: symbol lookup error: /opt/ruby-enterprise-1.8.7-2012.02/lib/ruby/gems/1.8/gems/tiny_tds-0.6.0.rc1/lib/tiny_tds/tiny_tds.so: undefined symbol: dbsetluser
The stack I'm running is:
Ubuntu 8.04
REE 1.8.7-2012.02
FreeTDS 0.92.377 (compiled from source)
TinyTDS 0.6.0.rc1 (also tried 0.5.1)
I can successfully connect to the SQL Server using isql, which leads me to think that FreeTDS and ODBC is set up correctly. But whenever I try to connect from Ruby with TinyTds, I get the above error.
I have tried posting to the Google group for rails-sqlserver-adapter, but the forum seems moderated and my question has not yet shown up.
I'm fairly certain it has to do with TinyTds not finding the libraries (which I believe should be available somewhere), but I do not know how to achieve this.
As a last resort, I am going to start building a server from scratch with 12.04, but I would much prefer to get the existing system working.
As per #Casper's suggestion I have tried connecting with odbc and now I get a different error
irb > require ‘odbc’
irb > ODBC.connect('dsn', 'username', 'password')
[unixODBC][FreeTDS][SQL Server]Unable to connect to data source`
even though I can successfully connect with isql and sqsh.
It all had to do with environment variables. It seems like after installing freetds and odbc, the environment variables for FREETDSCONF, ODBCINI and ODBCSYSINI were not made available to Ruby. I had to add them to my user's .bashrc and /etc/profile as well as in my Apache config in order to get Passenger to see them (using SetEnv).
Hope this helps someone in the future.

unable to start Alfresco 3.4.4 (Error while starting postgresql)

I am using Alfresco 3.4.4 in my production environment(Redhat Linux). Yesterday I just tried to restart my Alfresco server but now it's not starting up. The tomcat starts successfully but postgres throws an exception while starting the server (here I am using postgres DB that was bundled with alfresco and haven't modified anything in the configuration files).
I manually tried to start the postgresql server from alfresco/postgresql/scripts/ctl.sh and got the following error:
error while loading shared libraries: libssl.so.0.9.8: cannot open
shared object file: No such file or directory
Then I executed the following commands (I found this solution somewhere on the net):
$ cd /postgresql/bin
$ . setenv.sh
$ ldd initdb.bin
After executing these commands I didn't get any error related to libssl.so but still I am not able to start the Postgres server and I only get the following error:
./ctl.sh : postgresql could not be started
Edit: ldd command gives the following output:
linux-vdso.so.1 => (0x00007fff4251e000)
libssl.so.0.9.8 => /opt/alfresco-3.4.4/common/lib/libssl.so.0.9.8 (0x00002b2e2c607000)
libcrypto.so.0.9.8 => /opt/alfresco-3.4.4/common/lib/libcrypto.so.0.9.8 (0x00002b2e2c755000)
libz.so.1 => /opt/alfresco-3.4.4/common/lib/libz.so.1 (0x00002b2e2c9cb000)
libreadline.so.5 => /opt/alfresco-3.4.4/common/lib/libreadline.so.5 (0x00002b2e2cae5000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x000000338a200000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003377c00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003377400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003377000000)
/lib64/ld-linux-x86-64.so.2 (0x0000003376c00000)
I had exactly the same problem and found the solution.
You have to do these commands in the /postgresql/bin directory of alfresco :
$ . setenv.sh
$ ldd initdb.bin
And after that (I think your problem is here now), stop the postgresql database, and alfresco :
$ service postgresql stop
$ sh /opt/alfresco.../alfresco.sh stop
Then start Alfresco :
$ sh /opt/alfresco.../alfresco.sh start
Then if you restart alfresco or your server, you might need to stop the postgresql service and alfresco and then start alfresco.
Your problem is already resolved but it can help someone else who will have this problem.
Interestingly this shows how unhelpful the messages of wrapper scripts can be. You may want to note for future cases that it is worth checking PostgreSQL server logs for startup failure reasons.
In your case what probably happened was that you had an unclean shutdown and the postmaster.pid was left around. This didn't get cleaned up by your startup script and so PostgreSQL thought it might already be running and so refused to start.