duetpluginservice(-root) not starting....
-
Hi *,
I just reimaged my pi with the latest duet raspi image which is connected to a Duet 3 MB6HC (1.0 or 1.01) but the two services "duetpluginservice" and "duetpluginservice-root" are not starting. The prompt does not come back when I try to start it manually with "systemctl start duetpluginservice.service".
The services are "dead" after a reboot":
root@blimy:~# systemctl | grep duet duetcontrolserver.service loaded active running Duet Control Server duetpluginservice-root.service loaded inactive dead start Duet Plugin Service (root) duetpluginservice.service loaded inactive dead start Duet Plugin Service duetwebserver.service loaded active running Duet Web Server
It seams to work when I start it manually:
root@blimy:~# /opt/dsf/bin/DuetPluginService Duet Plugin Service v3.5.3 Written by Christian Hammacher for Duet3D Licensed under the terms of the GNU Public License Version 3 [info] DuetPluginService.Program: Settings loaded [info] DuetPluginService.Program: Connection established [info] DuetPluginService.Program: Plugin DuetPiManagementPlugin loaded [info] Plugin DuetPiManagementPlugin: Process has been started (pid 1472)
It looks OK to when I do the same when I do it as the dsf user (after allowing the login).
There is nothing in the logs unfortunately:
root@blimy:~# journalctl -u duetpluginservice-root.service -- No entries -- root@blimy:~#
Any idea what's wrong here?
Cheers, Chriss
-
@Chriss One for @chrishamm to investigate.
Ian
-
@Chriss You can enable them again on boot time by running
sudo systemctl enable duetpluginservice
andsudo systemctl enable duetpluginservice-root
. I don't know why they were disabled on your setup. -
@chrishamm Oh, they are not disabled as you see, they are "inactive". I enabled them manually (just in case) and rebooted a couple of times. It seems that they do nothing at all.
It is very strange to be honest, I see no reason why they shout not start even if I start them with a "systemctl start ....". I have never ever seen a daemon on a UN*X like system with never come back after you started it. (Well, at least not if it is not totally malfunction)
And I would expect at least any kind of message on stdout or in the system log, but there is simply nothing.
I did not thing to the image, I downloaded the latest version, dd it to the SD card, booted the pi and did a "apt update ; apt upgrade -y", that's it. I came across the issue when I tried to start the "DuetPi Management Plugin".root@blimy:~/SD-Card/sys# ls -al /etc/systemd/system/multi-user.target.wants/duet* lrwxrwxrwx 1 root root 50 Sep 19 17:17 /etc/systemd/system/multi-user.target.wants/duetpluginservice-root.service -> /lib/systemd/system/duetpluginservice-root.service lrwxrwxrwx 1 root root 45 Oct 15 15:38 /etc/systemd/system/multi-user.target.wants/duetpluginservice.service -> /lib/systemd/system/duetpluginservice.service lrwxrwxrwx 1 root root 41 Sep 19 17:17 /etc/systemd/system/multi-user.target.wants/duetwebserver.service -> /lib/systemd/system/duetwebserver.service root@blimy:~/SD-Card/sys#
Edit: Changing the shell of the user dfs to bash is the only thing I have changed in the meantime. I needed to do that to su to the user to see how the bin behaves when I start it manually to see if there is any error report.
Cheers, Chriss
-
Nobody with an idea?
-
@Chriss Both DPS units depend on DCS so they won't start unless that service is active. AFAIR, the install scripts don't start these services again if they were disabled/stopped before the installation commenced. I don't know why these units were dead on your setup, they've worked OK on mine for a very long time and the corresponding systemd files haven't changed recently.
-
@chrishamm Strange, most strange.... Is there a am64 repo for that? I would like to play with that in a VM.
Am I right when I assume that we need to have the process running twice, one as uid 0 and one as the dsf? I will create two supervisord script to manage the processes till I found the reason for that behavior via the systemd.
I'm confused that I'm the only person reporting that, I used the most recent raspberry image from the duet homepage and I did not altered anything.
Needless to say that I want my init system back.
Cheers, Chriss
-
@Chriss said in duetpluginservice(-root) not starting....:
Is there a am64 repo for that? I would like to play with that in a VM.
No. You could build it from the sources for different architectures but since it requires an SPI link to work I guess that's rather pointless.
@Chriss said in duetpluginservice(-root) not starting....:
Am I right when I assume that we need to have the process running twice, one as uid 0 and one as the dsf?
Yes.
@Chriss said in duetpluginservice(-root) not starting....:
I'm confused that I'm the only person reporting that, I used the most recent raspberry image from the duet homepage and I did not altered anything.
If anything went wrong during start-up, the journal should tell you. No idea why they were empty on your machine, though. They should be enabled by default. What variant are you using, 32 or 64-bit, with or without GUI?
-
@chrishamm said in duetpluginservice(-root) not starting....:
@Chriss said in duetpluginservice(-root) not starting....:
Is there a am64 repo for that? I would like to play with that in a VM.
No. You could build it from the sources for different architectures but since it requires an SPI link to work I guess that's rather pointless.
OK, so no VM than, I will grep a other PI than for testing that.
@Chriss said in duetpluginservice(-root) not starting....:
I'm confused that I'm the only person reporting that, I used the most recent raspberry image from the duet homepage and I did not altered anything.
If anything went wrong during start-up, the journal should tell you. No idea why they were empty on your machine, though. They should be enabled by default. What variant are you using, 32 or 64-bit, with or without GUI?
64 and without GUI.
Cheers, Chriss