I was trying to let geth run in background so I don't have to keep my terminal session alive or get rid of annoying block sync log by using nohup:

nohup geth --testnet &

However geth seemed to hang even though the process existed when I checked with:

ps aux | grep geth

and I couldn't attach another geth session because:

geth attach ipc:/Users/myname/Library/Ethereum/testnet/geth.ipc


Am I doing anything wrong or it's just that geth is not supposed to run in background which is completely nonsense to me.

Edit 1:

I did try to watch the log to see if the server can do anything:

tail -f nohup.out

Nothing was there that's why I thought geth seemed to hang.

  • 1
    Can you run as: geth --testnet ?
    – alper
    Commented Dec 31, 2016 at 21:30
  • Sure I can run geth --testnet successfully
    – vutran
    Commented Jan 1, 2017 at 4:05

3 Answers 3


Since you can run geth --testnet successfull, there should be no problem with geth. Please be sure to use latest version of geth.

$ sudo apt-get install git
$ git clone https://github.com/ethereum/go-ethereum
$ sudo apt-get install -y build-essential libgmp3-dev golang
$ cd go-ethereum/
$ param update
$ git pull
$ make geth

Based on your comment:

geth is not supposed to run in background

You may have to run geth as being sudo, my geth.ipc file required root access.

Fatal: Unable to attach to remote geth: dial unix /Users/myname/Library/Ethereum/testnet/geth.ipc: 
connect: permission denied

I had overcome this issue as follows:

First create a "server.sh" file:

nohup geth --testnet &
echo 'loadScript("pass.js")' | sudo geth ipc:/Users/myname/Library/Ethereum/testnet/geth.ipc console #You are not required to add this line.
echo 'net'                   | sudo geth ipc:/Users/myname/Library/Ethereum/testnet/geth.ipc console #You are not required to add this line.

//If you have an additional script you can load and/or check net status after geth starts running.

Than create "client.sh" file: I assume your datadir is at /.ethereum

sudo geth ipc:/Users/myname/Library/Ethereum/testnet/geth.ipc console

Run following command: //This will run geth on the background with the help of nohup.

$ sudo bash server.sh

At final step when you run this command, you will be attached:

$ bash client.sh

You can observe the log file on "nohup.out" file.

$ sudo cat nohup.out
  • 1
    Your suggestion of running it under sudo works for me, now I can have nohup successful detached geth process. However, I still don't understand why exactly do we need to run it under sudo. What's the difference between nohup and an attached process that deal with permission? Avoiding sudo when don't really need to is recommended isn't it?
    – vutran
    Commented Jan 1, 2017 at 8:15
  • There is no difference, you just have to run geth with sudo, either if you are using nohup or not. This problem is related to geth.ipc, where it requires root access.
    – alper
    Commented Jan 1, 2017 at 9:24
  • Then I don't think you are right in my case. Since geth is running under my non-root account and it creates the geth.ipc thus geth.ipc should be accessible without root permission. Evidence is that I could successfully attach a geth session to the ipc while running geth without child process (& or nohup). There should be still something missing here.
    – vutran
    Commented Jan 1, 2017 at 9:27
  • You may try chmod o+w geth.ipc , The o+w command tells the system you want to give others write permission to the file. This may remove the usage of sudo.
    – alper
    Commented Jan 1, 2017 at 9:27
  • 1
    Let us continue this discussion in chat.
    – vutran
    Commented Jan 1, 2017 at 10:42

Just a troubleshooting idea. As far as I know, nohup and geth should be a valid combination.

Probability is that nohup is working fine but geth isn't behaving the way you expect. Possibly geth isn't getting far enough to start/support the IPC connection. No IPC doesn't mean geth is completely dead. Consider logging the output with >> geth.log

$ nohup geth --testnet >> geth.log &

and watching with

$ watch geth.log

You can make geth more talkative than usual with --verbosity

$ nohup geth --testnet --verbosity 5 >> geth.log &

Also, be sure you're IPC connection is pointing to a valid path. There should be a geth.ipc visible in that folder. I would make sure that much works using multiple terminals, and then re-introduce nohup into the mix.

In my case (yours might differ) testnet ipc path would be:


Dot in front of "ethereum" is important. The folder is hidden, but it's there.

  • I have no problem with ipc path because I can run it successfully without child process. My thinking process was the same as you suggested but there's something different. You suggested to use >> to direct output to a file, I usually use single > to do so. Is there any different? I find it strange to use >>. Anw, please see my updated question.
    – vutran
    Commented Jan 1, 2017 at 4:10
  • 2
    >> just concatenates the log instead of overwriting it every time. Possibly someone can chime in with an insight about nohup. Commented Jan 1, 2017 at 4:50
  • If you're starting geth from an unstable remote connection and you need it to keep running, screen might be good option. For local ops, I use terminator, but it's a matter of taste. Commented Jan 1, 2017 at 4:54
  • Yeah, I know that there exists some other solutions. But I really want to dive into this to know exactly what's wrong because I never been failed using nohup before. I do think that geth is doing something strange to some UNIX signals relatedto child process.
    – vutran
    Commented Jan 1, 2017 at 4:58

You can have Geth run as a systemd service. Refer to here: https://github.com/bas-vk/config/blob/master/geth-systemd-service.md


You could also run the Geth Docker container and detach using the -d tag.


Start a screen/Tmux session, run Geth then detach.

  • I really appreciate your answer, however i want to know how nohup and child process didn't work?
    – vutran
    Commented Dec 31, 2016 at 19:22
  • 1
    Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – q9f
    Commented Jan 1, 2017 at 0:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.