I have created a simple Qt console application (dbus service) and I need to launch it using systemd.
However every time I execute systemctl start my_serv it fails to start the application and I end up having log in journalctl -xe indicating that application has failed to load libQt5Gui.so.5 (i'm pretty sure it is not related to this particular library):
raspberrypi systemd[1]: Started my_serv.service.
raspberrypi MyService[2812]: /opt/services/MyService: error while loading shared libraries: libQt5Gui.so.5: cannot open shared object file: No such file or directory
raspberrypi systemd[1]: my_serv.service: main process exited, code=exited, status=127/n/a
raspberrypi systemd[1]: Unit my_serv.service entered failed state.
From the other hand application launches fine when I do this from console under root user (i.e. it fails to register an object on dbus, but I think it is not relevant):
./MyService
WELCOME FROM MY SERVICE
Object was registered on dbus
Service was not registered on dbus
Qt libraries are locates by the following path:
ls -al /usr/local/qt5/lib/libQt5Gui.*
-rwxrwxrwx /usr/local/qt5/lib/libQt5Gui.la
-rwxrwxrwx /usr/local/qt5/lib/libQt5Gui.prl
lrwxrwxrwx /usr/local/qt5/lib/libQt5Gui.so -> libQt5Gui.so.5.9.1
lrwxrwxrwx /usr/local/qt5/lib/libQt5Gui.so.5 -> libQt5Gui.so.5.9.1
lrwxrwxrwx /usr/local/qt5/lib/libQt5Gui.so.5.9 -> libQt5Gui.so.5.9.1
-rwxrwxrwx /usr/local/qt5/lib/libQt5Gui.so.5.9.1
It seems that everything is fine with links to libraries in the binary. The ldd output is as follows:
ldd MyService
libQt5Gui.so.5 => /usr/local/qt5/lib/libQt5Gui.so.5 (0x76a92000)
libQt5DBus.so.5 => /usr/local/qt5/lib/libQt5DBus.so.5 (0x76a0d000)
libQt5Core.so.5 => /usr/local/qt5/lib/libQt5Core.so.5 (0x7654e000)
The service file looks like this (/etc/systemd/system/my_serv.service)
[Service]
ExecStart=/opt/services/MyService
User=root
Most probably the linker directories are not known in the context of systemctl. Try setting the environment variable LD_LIBRARY_PATH to the relevant dirs at the start of your service script; see man ld.so for details. Or look at other service scripts on your system to get an idea how the environment is correctly set there.
You can check /etc/ld.so.conf file, example the content is include ld.so.conf.d/.conf.So,you can type a new file under /etc/ld.so.conf.d/ , and put your base path of libQt.so to the file . exmaple:usr/local/qt5/lib/.
And last, execute ldconfig.
Related
I have simple console application, I want to run application as service in ubuntu.
I have created .service file in /etc/systemd/system folder HelloWorld.service as below
[Unit]
Description=HelloWorld Application
[Service]
ExecStart=/usr/share/dotnet/dotnet /home/prasadg/HelloWorld/dev/HelloWorld.dll
SyslogIdentifier=HelloWorld
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
after I saved file I have reload daemon with command
systemctl daemon-reload
then I have started newly created service systemctl start HelloWorld
it get started and nothing happens, after sometime, when I checked status using command systemctl status HelloWorld it shows error as below
HelloWorld.service - HelloWorld Application
Loaded: loaded (/etc/systemd/system/HelloWorld.service; disabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: core-dump) since Tue 2022-06-28 21:20:13 IST; 4s ago
Process: 28389 ExecStart=/usr/share/dotnet/dotnet /home/prasadg/HelloWorld/dev/HelloWorld.dll (code=dumped, signal=ABRT)
Main PID: 28389 (code=dumped, signal=ABRT)
if try run directly with command as /usr/share/dotnet/dotnet /home/prasadg/HelloWorld/dev/HelloWorld.dll it runs successfully
A full log message would help more, but I guess you need to add a WorkingDirectory to your HelloWorld.service.
Running Artifactory 6.3.3.
Trying to start the service produces the following error in systemd:
artifactory.service: New main PID 1359 does not belong to service, and PID file is not owned by root. Refusing.
After which it just goes into a continuous restart loop.
This seems to be consistent with the following systemd issue:
https://github.com/systemd/systemd/issues/8085
I had my new Nexus 3 repository running okay. I was able to configure some of the basic settings. Then I went through the process of enabling SSL. I used the instructions here. I also watched the video on that page, which does not give instructions that match the page.
My system info: ubuntu 14.4 with Java 8.
Install directory: /opt/nexus-3.0.0-b2016011501/
To simplify the path, I created a link to this directory: nexus -> /opt/nexus-3.0.0-b2016011501/ therefore the path to nexus is /opt/nexus
I generated my keystore as follows:
Created directory: /opt/nexus/etc/ssl
Changed to that directory and ran: keytool -keystore keystore -alias jetty -genkey -keyalg RSA -validity 3650. This generated a file called keystore. I then copied that file to keystore.jks.
Updated the following files: /opt/nexus/etc/org.sonatype.nexus.cfg added application-port-ssl=443 and added ${karaf.etc}/jetty-https.xml(this is different from the written instructions) to the end of the nexus-args=$ line. Then (this is in the video, but not the written instructions) I edited the /opt/nexus/etc/jetty-https.xml file and replaced the password in three places with the password I specified when I generated my keystore.
After this if I start nexus with ./nexus run it get the following error:
2016-01-27 02:20:41,013+0000 ERROR [jetty-main-1] *SYSTEM org.sonatype.nexus.bootstrap.jetty.JettyServer - Failed to start
java.net.SocketException: Permission denied
at sun.nio.ch.Net.bind0(Native Method) [na:1.8.0_72]
at sun.nio.ch.Net.bind(Net.java:433) [na:1.8.0_72]
at sun.nio.ch.Net.bind(Net.java:425) [na:1.8.0_72]
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) [na:1.8.0_72]
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) [na:1.8.0_72]
at org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326) [org.eclipse.jetty.server:9.3.5.v20151012]
at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80) [org.eclipse.jetty.server:9.3.5.v20151012]
at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244) [org.eclipse.jetty.server:9.3.5.v20151012]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [org.eclipse.jetty.util:9.3.5.v20151012]
at org.eclipse.jetty.server.Server.doStart(Server.java:384) [org.eclipse.jetty.server:9.3.5.v20151012]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [org.eclipse.jetty.util:9.3.5.v20151012]
at org.sonatype.nexus.bootstrap.jetty.JettyServer$JettyMainThread.run(JettyServer.java:274) [org.sonatype.nexus.bootstrap:3.0.0.b2016011501]
If it start it with sudo ./nexus run it will work but shows me the nag message saying I should not run it as root.
I have verified that my user is the owner of all the files and directories /opt/nexus
On Linux (and other unix type systems) you can't run on port numbers less than 1024 unless you are root. The best way to solve this is to run Nexus behind a reverse proxy. You can find instructions for this here:
http://books.sonatype.com/nexus-book/reference/install-sect-proxy.html
The above was written for Nexus 2.x, but the configuration needed will be the same in Nexus 3.
Regarding running as non-root as a service, there is a bug in 3.0m7 that makes this problematic:
https://issues.sonatype.org/browse/NEXUS-9437
The fix is to edit the "bin/nexus" startup script is to replace this line:
INSTALL4J_JAVA_PREFIX="su - $run_as_user -c"
With this:
exec su - $run_as_user "$prg_dir/$progname" $#
This fix will be in the next release.
Once that change is made, symlink $NEXUS_HOME/bin/nexus to /etc/init.d/nexus, then install the service. And edit "$NEXUS_HOME/bin/nexus.rc" and set the "run_as_user" appropriately.
I am trying to create a GCE instance image from its startup script (just after some setup instructions). I use a command line looking like :
gcimagebundle -d "/dev/sda" -o "/tmp/" --log_file=/var/log/image_generation.log "--output_file_name=/tmp/myimage.tar.gz"
After few seconds the gcimagebundle exits and I get the following error message (from the /var/log/image_generation.log file) :
INFO:root:found platform Centos
INFO:root:File System: ext4
INFO:root:Disk Size: 10737418240 bytes
INFO:root:Resolved /dev/sda to /dev/sda
INFO:root:exclude list: (/etc/ssh/.host_key_regenerated, 0:0:0) (/dev, 0:1:0) (/proc, 0:1:0) (/run, 0:1:1) (/selinux, 0:0:0) (/tmp, 0:1:0) (/sys, 0:1:0) (/var/lib/google/per- instance, 0:1:0) (/var/lock, 0:1:1) (/var/log, 0:1:1) (/var/run, 0:1:1)
INFO:root:ignoring mounts /proc /sys /dev/pts /dev/shm /proc/sys/fs/binfmt_misc
WARNING:root:overwrite list =
INFO:root:Initializing disk file
INFO:root:Making filesystem
INFO:root:Copying contents
WARNING:root:Error while running ['rsync', '--times', '--perms', '--owner', '--group', '--links', '--devices', '--acls', '--sparse', '--hard-links', '--recursive', '--xattrs', '--exclude-from=/tmp/tmpXtECHY/tmp6Y_7Dr', '/', '/tmp/tmpXtECHY/tmpencYI_'] return_code = 11
stdout=
stderr=rsync: failed to open exclude file /tmp/tmpXtECHY/tmp6Y_7Dr: Permission denied (13)
rsync error: error in file IO (code 11) at exclude.c(1062) [client=3.0.6]
I tried to execute the same startup script on a fresh instance after a manual sudo su and all works.
I execute a whoami from the startup script and the result is root.
I have an embedded Linux board that uses systemd for startup processes. I also have a GUI written in Qt that I can launch just fine from the command line and interact with using the board's touchscreen or buttons. To launch the app I usually do:
ssh root#192.168.1.2
cd ~/
./gui
I'd like this to startup automatically using SystemD so I wrote a service file that looks like this:
[Unit]
Description=The Qt Gui
After=dropbear.service systemd-logind.service
ConditionFileIsExecutable=/home/user/gui
[Service]
ExecStart=/home/user/gui
Restart=on-abort
[Install]
WantedBy=multi-user.target
When the board boots I see in the systemd log that it is starting my gui right after the dropbear SSH service:
[ OK ] Started Dropbear SSH2 daemon.
Starting The Qt Gui...
[ OK ] Started The Qt Gui.
And if I SSH to the board after it boots and run 'ps' I can see my process started ( and if I kill it it restarts as expected from systemd ):
196 root 26868 S /home/user/gui
The output of systemctl status looks OK to me, notice the last line 'ARM build' is a qDebug() print statement from my code:
gui.service - The Qt Gui
Loaded: loaded (/etc/systemd/system/gui.service; enabled)
Active: active (running) since Tue, 2012-11-20 21:30:20 UTC; 4min 35s ago
Main PID: 196 (gui)
CGroup: name=systemd:/system/gui.service
└ 196 /home/user/gui
Nov 20 21:30:20 systemd[1]: Starting The Qt Gui...
Nov 20 21:30:20 systemd[1]: Started The Qt Gui.
Nov 20 21:30:22 gui[196]: ARM build
However I can not interact at all with the instance of the GUI being launched using systemd! If I launch a secondary instance from the command line than I can press buttons or the touchscreen and the GUI pops up on the screen and works as expected. What gives? I've tried 'Type=forking' in the service file and this doesn't help either. Any ideas on what is wrong here? How can I get systemd to launch my Qt GUI just as if I did it from the command line? Thanks -
Thanks for the input above. It actually was not a working directory or timing issue. The problem was that my Qt GUI was not getting the proper environment variables that it needed for communicating with the touchscreen. Sourcing /etc/profile worked for me:
[Unit]
Description=The Qt Gui
After=dropbear.service
ConditionFileIsExecutable=/home/user/gui
[Service]
Type=simple
TimeoutStartSec=60
WorkingDirectory=/home/user
ExecStartPre=/bin/sh -c 'echo 127 > /sys/class/backlight/generic-bl/brightness'
ExecStart=/bin/sh -c 'source /etc/profile ; /home/user/gui -qws'
Restart=always
[Install]
WantedBy=multi-user.target