Is it possible the get the UID from within a systemd service file? - systemd

I have a service file which starts chromium on wayland:
[Unit]
Description=Launch Chromium
After=network.target weston.service
Requires=weston.service
[Service]
Type=simple
User=weston
Group=weston
Environment="XDG_RUNTIME_DIR=/run/user/1000"
Environment="WAYLAND_DISPLAY=wayland-1"
ExecStart=/usr/bin/chromium
TimeoutSec=infinity
[Install]
WantedBy=graphical.target
Normally the weston user gets assigned the UID 1000 (I'm building a Yocto image so the UID could change potentially if there were changes in the image). It would be nice if there was a way to get the UID from within the systemd service file so that the setting for XDG_RUNTIME_DIR variable is always valid.

Just set it to the first directory inside /run/user if you want to.
ExecStart=/usr/bin/sh -c "XDG_RUNTIME_DIR=$(find /run/user/ -maxdepth 1 -mindepth 1 | head -n 1) /usr/bin/chromium"
But instead, you should be running the service as a user service of the user that logs in inside the graphical console.

Related

Can systemd run a script after every mount, regardless of the mount point?

I need to execute a script every time a USB flash drive is inserted.
I can create a systemd service that runs a script after a mount:
[Unit]
Description=My Script
Requires=run-media-sdb1.mount
After=run-media-sdb1.mount
[Service]
ExecStart=/usr/bin/bin/my-script
[Install]
WantedBy=run-media-sdb1.mount
But this systemd service depends on a special mount point.
How can systemd start a service regardless of the mount point? Irrespective of whether, for example, sda1 or sdc3 is mounted, only one service should be necessary.
Thanks in advance for your help!

Firebase DB program works when logged in but not on boot using raspberry pi

I am creating an IOT device with raspberry pi and using firebase admin sdk to communicate over the web. The code works exavtly how I want it to... Until I try adding it into local.rc for using it headlessly.
I'm unable to copy the error as it is only being thrown on boot. Here is a picture.
https://drive.google.com/open?id=0B9zzhouEyyN_RmttYVVOZXE0d2JXNWtTZHBjTlZYRTZkdy1N
From what I can read it has to do with an authority problem from where the program is being run. This is my rc.local:
# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi
#My line
sudo sh /home/pi/superscript.sh
exit 0
the supercript is
sudo python home/pi/servo.py & sudo python home/pi/buttonCheck.py&
I've tried with and without sudo.
Thanks for any help.
I switched my process from running in rc.local to being a service in systemd, thanks to Kamil Cuk. Here is a link to the documentation for using systemd service method.
Though I am not experiencing any crashing, but putting Restart=Always will restart it after crash if applicable.
This is what it looks like.
[Unit]
Description=Room controller
After=multi-user.target
[Service]
Type=idle
ExecStart=/usr/bin/python /home/pi/servoController.py & /usr/bin/python /home/pi/buttonListener.py
Restart=always
[Install]
WantedBy=multi-user.target

Start-Up script for a running GCE instance

I just tried to set up a small start-up script for a running GCE instance. I added a custom meta-data with the key startup-script and value
#! /bin/bash
vncserver -geometry 1920x1080
However, it doesn't seem to be taken into account when I restart the instance. Moreover, trying to execute sudo google_metadata_script_runner --script-type startup doesn't give any result neither... What am I doing wrong?

How to vary start parameters in systemd service based on file existence?

I'm trying to write a service file for OpenLDAP. What I've got so far is:
[Unit]
Description=OpenLDAP server daemon
After=network.target
[Service]
Type=forking
PIDFile=/var/run/slapd/slapd.pid
ExecStartPre=-/bin/mkdir /var/run/slapd
ExecStartPre=/bin/chown openldap:openldap /var/run/slapd
ExecStart=/srv/openldap-latest/lib/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -F /etc/ldap/slapd.d
[Install]
WantedBy=multi-user.target
The problem is the "-F /etc/ldap/slapd.d" bit. When OpenLDAP is first set up, this directory doesn't exist, so you have to specify "-f /etc/ldap/slapd.conf" instead. I cannot see how to do this with systemd, though.
One option might be to define TWO different units - one starts if slapd.d exists and one starts if slapd.d doesn't exist - but the service still needs to be called the same thing otherwise administrators are going to get very confused, so I don't think that idea works out.
How can I solve this?
What about adding:
ExecStartPre=-/bin/mkdir /etc/ldap/slapd.d
?

AWS Launch Configuration not picking up user data

We are trying to build an an autoscaling group(lets say AS) configured with an elastic load balancer(lets say ELB) in AWS. The autoscaling group itself is configured with a launch configuration(lets say LC). As far as I could understand from the AWS documentation, pasting a script, as-is, in the user data section of the launch configuration would run that script for every instance launched into an auto scaling group associated with that auto scaling group.
For example pasting this in user data would have a file named configure available in the home folder of a t2 micro ubuntu image:
#!/bin/bash
cd
touch configure
Our end goal is:
Increase instances in auto scaling group, they launch with our startup script and this new instance gets added behind the load balancer tagged with the auto scaling group. But the script was not executed at the instance launch. My questions are:
1. Am i missing something here?
2. What should I do to run our startup script at time of launching any new instance in an auto scaling group?
3. Is there any way to verify if user data was really picked up by the launch?
The direction you are following is right. What is wrong is your user data script.
Problem 1:
What you have to remember is that user data will be executed as user root, not ubuntu. So if your script worked fine, you would find your file in /root/configure, NOT IN /home/ubuntu/configure.
Problem 2:
Your script is actually executing, but it's incorrect and is failing at cd command, thus file is not created.
cd builtin command without any directory given will try to do cd $HOME, however $HOME is NOT SET during cloud-init run, so you have to be explicit here.
Change your script to below and it will work:
#!/bin/bash
cd /root
touch configure
You can also debug issues with your user-data script by inspecting /var/log/cloud-init.log log file, in particular checking for errors in it: grep -i error /var/log/cloud-init.log
Hope it helps!

Resources