Arch Linux

kmsgli

Member

Registered: 2015-08-15

Posts: 28

systemd issue with storjshare

Hello guys this is a pretty specific issue I cant seem to search and find an answer too so hopefully someone can shed some light on it.

I am making a script to automate installing and setting up a Storjcoin farm.  I am mentioning it is storjcoin as maybe that has somehting to do with it not sure.  The script is much larger and more complex then what I will be posting and I have other issues with it but the other issues are storj config issues not arch issues. 

The script does this
makes a dir in the home folder (node1)
creates and enables a systemd service and places it in the /etc/systemd/system folder
creates a shell script for auto starting the storj program and setting the node status to up, script is then placed in ~/.config/storjshare/scripts
creates a storj config file and puts it in ~/.config/storjshare/configs (this does not work correctly yet but still makes a useable file)

when I run the shell script in my desktop environment it starts storj and sets the node to up

when I run the storjstart.service (sytemctl start) it does not start storj and set the node up

when i reboot systemctl tells me it successfully started storj and set the node up but when i check the command line interface it says storj daemon is not up try starting the storj daemon.

I recognize this is a very specific issue that may be a problem with storj software itself but the problem seems to me to be an issue with my systemd file maybe someone can point out a simple mistake?

here is the shell script unit:

#!/bin/bash

#start daemon
storjshare daemon

#wait 5 seconds
sleep 5s

#start faming node
storjshare start --config /home/******/.config/storjshare/configs/config.json

here is the systemd service

[Unit]
Description=Sorjshare start script

[Service]
ExecStart=/home/******/.config/storjshare/scripts/storjstart.sh
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Last edited by kmsgli (2018-04-22 23:59:33)

Trilby

Inspector Parrot

Registered: 2011-11-29

Posts: 29,523

Website

Re: systemd issue with storjshare

Using a system service for content all in a user's home director is odd, to say the least.  You could user a user service.  But more importantly, why are you trying to do any of this that way?  Why aren't you using the package in the aur?

---

"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

kmsgli

Member

Registered: 2015-08-15

Posts: 28

Re: systemd issue with storjshare

Using a system service for content all in a user's home director is odd, to say the least.  You could user a user service.  But more importantly, why are you trying to do any of this that way?  Why aren't you using the package in the aur?

The AUR package is just the program you still have to run all those commands manually and I am deploying the setup on about five computers and I wont have access to them all the time so I want the storj farm up upon reboot should there be a power outage or something.  Even if I was not automating the install setup I still cant get systemd to start storj upon reboot that is the crux of my issue.

If there is an easier way to get storj to start on reboot maybe not involving systemd I would love to know it.  Thanks for your help

Last edited by kmsgli (2018-04-22 22:34:11)

Steef435

Member

Registered: 2013-08-29

Posts: 577

Website

Re: systemd issue with storjshare

when I run the storjstart.service (sytemctl start) it does not start storj and set the node up

Relevant logs would be nice, like journalctl output for the unit and logs from the daemon itself.

EDIT: I agree with Trilby, I would let this run as a separate user (with all respect for nodejs and the project, I'd rather not run random javascript with root rights).

Last edited by Steef435 (2018-04-22 23:28:04)

loqs

Member

Registered: 2014-03-06

Posts: 17,321

Re: systemd issue with storjshare

Should it not be two services one for running the daemon and the second depending on the first to run a node after the daemon has started so the arbitrary sleep can be removed?

kmsgli

Member

Registered: 2015-08-15

Posts: 28

Re: systemd issue with storjshare

Should it not be two services one for running the daemon and the second depending on the first to run a node after the daemon has started so the arbitrary sleep can be removed?

Initially I also thought the same thing but tried it that way with mixed results so I assumed that was not really my issue as I cant see why systemd cant run these two very simple commands in one script.

That being said I have solved the problem but I cant exactly explain why.

[Unit]
Description=Sorjshare start script

[Service]
Type=forking
ExecStart=/home/*****/.config/storjshare/scripts/storjstart.sh

[Install]
WantedBy=multi-user.target

Changing Type=forking seems to have solved the issue and systemd can both start and put the node up on reboot as well as on demand with systemctl start.

All I can figure is storj needs the process to exit to be successful.  Of course I have been working on this for a while and when I gave up and posted on the forums I figured out the issue.

Thanks for all the input guys mark this as solved and I will change the title to include storj in case anyone searches for this later.

Last edited by kmsgli (2018-04-22 23:59:00)

loqs

Member

Registered: 2014-03-06

Posts: 17,321

Re: systemd issue with storjshare

           If set to forking, it is expected that the process configured with
           ExecStart= will call fork() as part of its start-up. The parent
           process is expected to exit when start-up is complete and all
           communication channels are set up. The child continues to run as
           the main daemon process. This is the behavior of traditional UNIX
           daemons. If this setting is used, it is recommended to also use the
           PIDFile= option, so that systemd can identify the main process of
           the daemon. systemd will proceed with starting follow-up units as
           soon as the parent process exits.

So what has systemd identified as the main process?

kmsgli

Member

Registered: 2015-08-15

Posts: 28

Re: systemd issue with storjshare

           If set to forking, it is expected that the process configured with
           ExecStart= will call fork() as part of its start-up. The parent
           process is expected to exit when start-up is complete and all
           communication channels are set up. The child continues to run as
           the main daemon process. This is the behavior of traditional UNIX
           daemons. If this setting is used, it is recommended to also use the
           PIDFile= option, so that systemd can identify the main process of
           the daemon. systemd will proceed with starting follow-up units as
           soon as the parent process exits.

So what has systemd identified as the main process?

Honestly I am not sure, I found a bunch of different variables when searching for systemd unit for shell script on boot.  Type=forking seemed to do the trick though.  Maybe someone who understands systemd better can chime in and tell us why.

Last edited by kmsgli (2018-04-23 00:32:36)