Linux background service difficulties (systemctl)

11 posts / 0 new
Last post
patm
Linux background service difficulties (systemctl)

I'm using Ubuntu 16 and attempting to get the server running in the background. I tossed vhusbdarm64 into /usr/sbin and at first I tried the script in the sticky above by changing $NAME then putting it in /init.d then

root@NanoPi-NEO2:/etc/init.d# update-rc.d virtualhere.sh defaults

But Ubuntu said:
insserv: Script virtualhere.sh is broken: incomplete LSB comment.
insserv: missing `Required-Start:' entry: please add even if empty.
insserv: missing `Required-Stop:' entry: please add even if empty.
insserv: missing `Default-Start:' entry: please add even if empty.
insserv: missing `Default-Stop:' entry: please add even if empty.
insserv: script virtualhere.sh provides system facility $remote_fs, skipped!
insserv: script virtualhere.sh provides system facility $syslog, skipped!
insserv: script virtualhere.sh provides system facility $remote_fs, skipped!
insserv: script virtualhere.sh provides system facility $syslog, skipped!
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `virtualhere.sh'
insserv: Default-Stop undefined, assuming empty stop runlevel(s) for script `virtualhere.sh'

So I tried a simple systemctl script but I obviously haven't sussed that out because although there were no errors showing it's not actually running according to htop or systemctl.

Of course it runs fine from command line as program or daemon.

Do you have a systemctl script for VH? According to Ubuntu at least, init.d style is going the way of the Dodo.

Michael
.

Ok i figure you got this fixed as the next post suggests so

patm
Actually I didn't - the

Actually I didn't - the daemon was from the command line. Been doing some reading though and it looks like the systemctl scripts are actually far more simple than I was thinking which is why I couldn't find any details. Going to mess around with it now that I've had dinner and a relax.

Michael
.

ok try adding what is says

insserv: missing `Required-Start:' entry: please add even if empty.
insserv: missing `Required-Stop:' entry: please add even if empty.
insserv: missing `Default-Start:' entry: please add even if empty.
insserv: missing `Default-Stop:' entry: please add even if empty.
patm
I've actually been working on

I've actually been working on the systemctl way of doing things. I've made a lot of headway but running into two issues:

1) It reads the config file but for some reason my license info doesn't appear to work - still says trial.
2) Sporadically stops by itself

#1 I'll email you if it turns out to be something other than my editing skills
#2 May also be my skills figuring out the .service file.

Here's what I've got so far:
[Unit]
Description=VirtualHere USB Sharing over Ethernet
After=syslog.target network.target

[Service]
Type=simple
PidFile=/var/run/virtualhere.pid
ExecStart=/usr/sbin/vhusbdarm64 -c /root/vhusbdarm64.ini -b

[Install]
WantedBy=multi-user.target

Not much to it. See anything missing or wrong?

And the .ini has

It=1505360018
Servername=NanoPI-Scope
Licence=alongandsecretnumberishthingy

Servername works, that shows up in the client.

Michael
.

Try putting in the other license code you received first via email

patm
Think I sorted the sporadic

Think I sorted the sporadic stopping. I had the type as simple then when i was staring at the many instances showing in htop it finally dawned on me that it would be forking instead. Changed to type=forking and it seems happy.

As for the license, I've copied and pasted it into /root/config.ini, /usr/sbin/config.ini and the specified /root/vhusbdarm64.ini as well as entering it in through the client. Nothing seems to work. I'll send the original email back to you and see if it's still valid. I do remember trying it on an RPI last year through the client and it was happy.

patm
Did a bit more experimenting

Did a bit more experimenting with the license thing. I stoped vh, deleted the config.ini's and remove the config file location from the .service file. Restarted vh and it created config.ini in /user/sbin.

Started the client, entered the license and no changes in the config.ini or even the serial/license displayed in the client.

Then I changed the hub name in the client and that did get written to /usr/sbin/config.ini - so I do have the right config file. It just doesn't like my license for some reason.

patm
Ok all fixed. Turned out it

Ok all fixed. Turned out it was me - license was for my old Rpi that I just experimented with once. Switched to arm64 license (thanks!) and its happy.

So my working /etc/systemd/system/ahusbdarm64a53.service file is

[Unit]
Description=VirtualHere USB Sharing over Ethernet
After=syslog.target network.target

[Service]
Type=forking
PidFile=/var/run/virtualhere.pid
ExecStart=/usr/sbin/vhusbdarm64a53 -c /root/vhusbdarm64a53.ini -b

[Install]
WantedBy=multi-user.target

Of course change vhusbdarm64a53 to whatever version you're using

Michael
.

OK looks good, that might be useful for others...

patm
Oh, I should probably

Oh, I should probably describe the steps to get that working too.

The above goes into /etc/systemd/ and you can name it anything you want (doesn't have to include the vh file name at all) so /etc/systemd/my.service would work too.
chmod 777 my.service (or whatever you called it)
systemctl daemon-reload #tells the system to read all the files and reconfigure. Run this anytime you make a change
systemctl enable my.service #Tells the system to run this at boot
systemctl start my.service #so you don't have to reboot to see how it works

That's all there was to it in the end.

Probably I should make a virtualhere user and change ownership of the files for security reasons but this will never be online so it probably wouldn't matter. Good exercise though since its looking more and more like I'll be dumping windows sometime in the foreseeable future.

Log in or register to post comments