The error about changing on the disk means just that the file is changed. After you run systemctl daemon-reload the file will be reread and hten you'll be able to start the service. You can use notifications as said in this manual pages. The type for the service is notify. Next thing is: you say your service type as forking. Does your process really forks? It is recommended to have PIDfile option set up if you use forking. With systemd it is not necessary to fork your process to become daemon.

After much frustration, I was able to get Chef to launch and persist JBoss with the following recipe: bash "Start JBoss" do cwd "/home/jboss/jboss-as-7.1.1.Final/bin" code <<-EOH sudo -u jboss start-stop-daemon --start --quiet --background --chdir /home/jboss/jboss-as-7.1.1.Final/bin --chuid jboss --exec /home/jboss/jboss-as-7.1.1.Final/bin/standalone.sh EOH end Many thanks to everyone who helped and to whomever wrote this: https://github.com/octo-technology/master-chef/blob/master/cookbooks/jboss/templates/default/jboss-as-standalone.sh.erb

What about usig nohup? http://en.wikipedia.org/wiki/Nohup nohup is a POSIX command to ignore the HUP (hangup) signal. The HUP (hangup) signal is by convention the way a terminal warns dependent processes of logout.

i changed the workspace to one which i used with my ex-eclipse, a lot of the codes were underlined red showing they have errors. This may be because in your project settings, you have the old jre associated, which may no longer be existing. There are multiple jre libs that are used in any java project. So you may have to change the old jre settings with the newly installed jre. Here is how you can do it: In eclise go to menu->window->preferences->java->installed JREs-> remove the old unavailable jre and add the new one.

did you try to deinstall it completely? check that the component is being removed at uninstall. components with marked as permanent (componentattributes) will never be removed. Neve be removed means they have a "shadowed" registration in the registry.

I did that on a standard debian 7, with a fresh openssl installed under /opt/openssl, like this $cd ~/ruby-src $./configure --prefix=/opt/ruby --without-openssl $make $sudo make install And then using ext/openssl/ $export PATH=/opt/ruby/bin:/opt/openssl/bin:$PATH $which ruby /opt/ruby/bin/ruby $which openssl /opt/openssl/bin/openssl $cd ~/ruby-src/ext/openssl/ $ruby extconf.rb --with-openssl-dir=/opt/openssl $make $sudo make install I had to comment out the line with OP_MSIE_SSLV2_RSA_PADDING in ossl_ssl.c, because that constant does not exist in the current openssl distribution, but then everything compiled cleanly.

Why don't you cache your data? You can either do that in process as a global variable. Depending on how you are running your server - multithreaded, multiprocessed, both - WSGI/Embedded - this may be easy or hard. Another option is to use memcached. Django caching is described here https://docs.djangoproject.com/en/dev/topics/cache/ http://www.jeffknupp.com/blog/2012/02/24/django-memcached-optimizing-django-through-caching/ It's very easy to use it. The interface is simply a get(key) and set(key,value). You can use various kinds of caches: Filesystem (you should probably use this with multiple processes) In memory (for single process and single thread try this - will be faster)

See this answer: RVM ruby on rails issue OpenSSL . Uninstall rvm, install openssl, install rvm Instructions from: http://www.dinduks.com/rails-cannot-load-such-file-openssl/ : This error means that your Ruby isn’t compiled with openssl. Assuming that you use RVM, these are the steps to follow to fix this issue. Install the openssl package rvm pkg install openssl Remove the Ruby installation you’re using rvm remove 1.9.3 And finally recompile Ruby with openssl rvm install 1.9.3 --with-openssl-dir=$HOME/.rvm/usr Everything should be working now. Don’t forget to: rvm use 1.9.3 --default Side note: I recommend installing rbenv instead of rvm.

Try removing everything from application.properties except the following lines: app.grails.version=2.1.1 app.name=connectwebapp plugins.tomcat=2.1.1 plugins.hibernate=2.1.1 Then, run grails clean Then, revert your application.properties and run grails run-app Hope that helps!!!

you rails thinks it should use --deployment / or --path from bundler - it's the path to gems: /Users/git/gitlab/vendor/bundle/ruby/2.0.0/gems, unfortunately bundler is nto smart enough and does not handle properly changes in ruby, you need to remove whole directory rm -rf /Users/git/gitlab/vendor/bundle and bundle install again. I would recommend you stop using --deployment / or --path flags from bundler, remove the directories rm -rf /Users/git/gitlab/vendor/bundle, rm -rf /Users/git/gitlab/.bundle/ and install gems in gemset, this way this problem will not happen again. In case of capistrano deployments set this flags for bundler/capistrano: set :bundle_dir, '' set :bundle_flags, '--system --quiet' to prevent using --deployment and --path flags with bundler.

This sometimes happens with Eclipse's Maven plugin. For some reason or other, it messes up its dependency mappings to the correct folders (ie. the library paths) when creating the classpath entry to run your application. In that case, the classpath is not correctly set and you get ClassNotFoundExceptions. You can usually fix this by forcing Maven to recalculate/set its paths by either restarting Eclipse or deleting the .m2 folder that holds all the downloaded jars. This folder is usually under your User folder in Windows, C:/Users/your.name.

// Disable watchdog on reset void wdt_init(void) __attribute__((naked)) __attribute__((section(".init3"))); void wdt_init(void) { // This is the flag that must be cleared on an ATTiny20 before the WDT can be disabled /***************/ /* RSTFLR = 0; */ /***************? wdt_disable(); return; }

No, there doesn't seem to be any difference. It is more to illustrate the git reset --soft (i.e. moving HEAD only, which can have other more practical uses) git reset HEAD is for "unstaging", and a simple git reset HEAD^ does both (move the HEAD, and unstage, no need for --mixed, since it is the default option) Here is a quick test to see what that looks like: Before (you just switch back to feature, where you committed a "wip" -- work in progress): C:UsersVonCproggit est 3>gl * 6ac95bd - (origin/master, origin/HEAD, master) fix in master (2 minutes ago) <VonC> | * fd8d97d - (HEAD, origin/feature, feature) snap WIP (3 minutes ago) <VonC> | * 16066dd - f1 (3 minutes ago) <VonC> |/ * e8ad96f - f1 (3 minutes ago) <VonC> The reset itself: C:UsersVonCproggit

I think there is an easiest way to install gcc on Fedora 19. Did you try with yum ? With something like sudo yum install gcc Your error means that the makefile which must be generated during the configure command doesn't exist because you don't have any c compiler. You can see details on the config.log file.

The .ssh directory and the authorized_keys files should be owned by the user logging in, and only readable by that user. The default ssh configuration will deny access if they are group or world readable. Check for an entry in /var/log/audit that might explain.

Executing c/c++ program with eclipse+unix base plate-forme, it requied object file of the program to execute/run it. So first of all you need to build your program by just pressing Ctr+b to buid it. This will create an object file that was required. Now you enabled to run/execute your programe. Good luck :)

<VirtualHost 127.0.0.1:80> ServerAlias www.list.dev DocumentRoot "/home/shavauhn/Desktop/Sites/List" ServerName list.dev </VirtualHost> there must be index.html or index.php or some index file in your document root to get it worked . . .

I had the same problem when install almost every theme on Fedora 19, Nautilus fails to respect gnome's theme settings. After some research, my best guess about why it happens is because most themes only support nautilus 3.6 but however in fedora 19 we have nautilus 3.8. And there is no way to downgrade. (I also tried your theme from http://satya164.deviantart.com/art/Numix-GTK3-theme-360223962 and with no luck, it doesn't work for me either. I'll update if I find a way)

The emulator is a 32-bit app. You need to install the equivalent 32-bit libraries. From the Fedora wiki HOWTO Setup Android Development the recommended libraries are: glibc.i686 glibc-devel.i686 libstdc++.i686 zlib-devel.i686 ncurses-devel.i686 libX11-devel.i686 libXrender.i686 libXrandr.i686 If you can run the emulator without GPU support I will assume you have all of those. For mesa-libGL your yum command is attempting to install the 64-bit version of the library, so try this instead: yum install mesa-libGL.i686 EDIT (after Question update): Yes install the The xorg-x11-drv-ati driver if it isn't already. This is the opensource driver and if it doesn't work you should just drop back to whatever you are running now. I have an Nvidia card, but have had this running

PyDev is finding the gurobi python libraries. The gurobipy python library is not able to find the native shared libraries. You need to add the location of libgurobi55.so to your LD_LIBRARY_PATH environment variable.

The full answer depends on your server configuration and how you're using MySQL. However, it's completely feasible to modify your SELinux policy to allow MySQL to run. In most cases, this sort of operation can be performed with a small number of shell commands. Start by looking at /var/log/audit/audit.log. You can use audit2allow to generate a permission-granting policy around the log messages themselves. On Fedora 19, this utility is in the policycoreutils yum package. The command # grep mysql /var/log/audit/audit.log | audit2allow ...will output the policy code that would need to be compiled in order to allow the mysql operations that were prevented and logged in audit.log. You can review this output to determine whether you'd like to incorporate such permissions into your syste

C++11 regular expression is not fully supported in GCC until 4.9 (current trunk as of this writing). For details check http://gcc.gnu.org/gcc-4.9/changes.html, under section "Runtime Library (libstdc++)".

I found the bug. It is the MOngoDB rpm fault. Mongo is looking for /var/run/mongo/mongod.pid and the path is /var/run/mongodb/mongodb.pid. Hope they will fix this. As for now no fix for this in fedora 18/19.

Fedora 18 with GCC 4.7.2/GLIBC 2.16 is an officially supported distro for CUDA 5.5 RC. Fedora 19 is not, nor is there any indication of support for GCC 4.8.x. I'm not surprised you're having trouble. The libcuda.so you see in /usr/lib64/nvidia was linked against a different version of GLIBC (2.16) than the one that is most likely on your machine (2.17). The only way forward with Fedora 19 that I can imagine would be to downgrade your (i.e. install an alternate) GCC/GLIBC to the one that comes with Fedora 18. It might be easier just to switch to Fedora 18.

I ran into the same problem on my Red Hat box. I fixed it by going to the referenced file and line number : /usr/lib64/python2.7/site-packages/clewn/gdb.py:340 and making the following fix: Starting on line 328: version = ''.join(takewhile(lambda x: x.isdigit() or x == '.', version[1])) and changing it to: version = ''.join(takewhile(lambda x: x.isdigit() or x == '.', version[1][1:])) The problem is how it's dealing with the first '(' character in the version string: [root@localhost ~ 03:52 PM] $ gdb -v GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change

It seems @jet47 has elected not to respond to my request in the comments, so I'm posting this answer so that we can call this question answered (which it clearly has been in the comments.) Make sure that you only have one installed OpenCV version, if you experience a problem like this. If you locate other installed versions besides the one intended, remove them.

You are missing the --cflags but, above all, The order is wrong. Check out Tor Lillqvist's suggestion for proper flags ordering.

You may not have the source code for that function available, or the include paths may not tell Eclipse where the appropriate code is located. Did you write this function? Or where is this function coming from? I am led to believe that you're probably using some 3rd party library without the source code being available to eclipse, and eclipse cannot just invent the declaration on its own.

App.reset only destroys Ember's generated objects. Classes are untouched. You will need to extend the reset method and do this cleanup manually. App = Ember.Application.create({ reset: function() { this._super(); App.Person.people = []; } });

I also tried all the answers given in this link Ubuntu - Error: Failed to create the SD card Try moving the android sdk folder to home folder. It works.

I have found the answer. I am using a 64bit version of Fedora, and trying to use 32bit libraries. I assumed that because I was developing a 32bit application, that I should use 32bit libraries. But, it worked when I uninsulated the 32bit and installed the 64bit libraries. Also, eclipse on Linux assumes that the 'lib' prefix and '.so' postfix exist, so you do not need them when you add them to the linker within eclipse (just SDL2).

Permanent network settings are stored in various files in /etc/networking and /etc/network-scripts. You could use diff to compare what's in those files between the system. However, that's just the network stuff (static v.s. dynamic, routes, gateways, iptables firewalls, blah blah blah). If there's no differences there, you'll have to start expanding the scope of your search.

YES! It comes and goes with time or development, and you will get different results in different browsers (ubuntu). I currently am getting Uncaught ReferenceError: Package is not defined meteor.js:21 Uncaught ReferenceError: Package is not defined standard-app-packages.js:21 Uncaught ReferenceError: Package is not defined random.js:21 etc A few weeks ago, chrome canary was bad but release chrome not. It may be some subtle code issue triggers things because as I developed madly but checked intermittently that problem came and went maybe three times, and once another browser gave me a clue on something it didn't like, which also cured chrome. I don't have any tools/concepts to debug this further. I initially got through Discover Meteor using chrome about 2 months ago.

Installing JDK on Fedora: 1 ) Please visit sun java website to download any java jdk version you like. http://java.sun.com/javase/downloads/index.jsp 2 ) Click download, select Linux platform, language and accept license and continue. 3 ) Select “Linux RPM in self-extracting file” and download jdk_filename-rpm.bin file (jdk-6u6-linux-i586-rpm.bin). 4 ) After downloaded, changed to the directory where you saved the file. 5 ) login to root user or su to root or sudo, and issue ‘chmod +x jdk_filename.-rpm.bin’ to make it executable. chmod +x jdk_filename.bin 6 ) Execute it ./jdk_filename-rpm.bin 7 ) Press space bar , repeat until system prompt to enter yes or no, type y and enter to continue. 8 ) This will output a .rpm file in same directory 9 ) Issue rpm -i jdk_filename

Eclipse uses this '.lock' files to avoid opening two eclipse instances over the same workspace. If the lock file is not writable, it won't work. I would try to manually remove the mentioned lock file. About the exit code 14, see related question and answers JVM terminates with exit code 14 when trying to launch Eclipse

DOMDocument is part of the "DOM" PHP extension. If you compile PHP from source, this gets included by default. Enterprise Linux-based systems require more than just the php module to be installed to get a full PHP installation. The second error is caused by a missing multi-byte string module. You can install these manually without having to recompile PHP. To do this using Puppet, add the following to your init.pp file: package { "php-mb": ensure => "5.3.3-22.el6" } package { "php-xml": ensure => "5.3.3-22.el6" } Where the version numbers match the version of PHP you already have installed. This is equivalent to: yum -y install php-mb php-xml Behat will now initialise and run without error.

You could try to use popen(3) to run and read the output of command /usr/bin/lsb_release -ds. If that fails, you might read and parse /etc/issue Notice that clever or paranoid sysadmins might edit and configure that /etc/issue file at will. But I don't understand why you want to know all that (from inside a C program), in other words, why the uname syscall is not enough. In particular, there are a lot of Debian (or Redhat) derived specialized distributions, and I don't understand why the name of the particular distribution would matter to a C program. It matters much more for packaging purposes....

Proper cross-compilation for OCaml currently requires a set of patches which you can find at http://caml.inria.fr/mantis/view.php?id=5737 ; the patches are being integrated in the trunk version of ocaml right now, so I guess that bug report should contain the latest information.

First thing I would say without even looking at your code would be to do a redirect in your code back to the original URL once processing has finished correctly. This is a standard practice for many types of problems, including keeping someone from refreshing a cart checkout page and having a payment submitted twice. By redirecting to the original page with no parameters being passed, you are essentially clearing out the data yourself.

Yes, there are polyfills to do exactly that. But there are so many things you'd need to fix that you can't put all fixes in one single script :-) Have a look at the HTML5 Cross Browser Polyfills list. If you're specifically interested in EcmaScript compliance, there are ES5 shims to retrofit missing or incorrectly implemented methods like String::trim; yet they can't fix the engine bugs (identifier-keywords, NFEs, …).