0

I started a little project. I want to have a different default desktop environment selected in GDM (log-in screen) depending on whether I am running it on a hypervisor or simply baremetal. I have already created a script that has the basic logic to detect how it's being run, then changes the default entry appropriately. What I am concerned with is automatically running this script on startup, which swaps the value of XSession in /var/lib/AccountsService/users/jeremy to either gnome or gnome-classic (refer to this for more info). I have several questions regarding this:

  • How should I properly create the .service file to make sure my script (located at /opt/DetectENV/switcher.sh) gets executed before the AccountsService loads during startup? (I am using Fedora 30 Workstation if that helps)

  • Where is the best place to put this .service file? Not sure if it should be /etc/systemd/system/ or /etc/systemd/user.

jerz4lunch
  • 9

1 Answers1

0

Use the option Before=accounts-daemon.service in [Unit]. This will work the same way as if accounts-daemon had an After= for your service: if both units are queued, then its startup will be delayed until your service completes initialization.

(This also means your service must use the correct type, i.e. usually Type=oneshot, to let systemd know when its initialization has in fact completed. In this case, because you want to run a simple command and wait until that command has exited, Type=oneshot is the correct choice.)

Note that your service must already be configured to start on boot in the normal way (that is, via WantedBy= and systemctl enable). The Before/After= options don't declare dependencies; they don't do anything more than inform systemd of the correct order.

All privileged services are system services. The only time you would create a 'user' service is when you want it to be started after you log in and bound to your user account. (For example, Dropbox or gnome-settings-daemon can be 'user' services.)

(Additionally, because 'system' and 'user' services are managed by entirely separate instances of systemd, ordering and dependencies only work between units within the same instance. That is, system units can only refer to other 'system' units; user units can only depend on other 'user' units.)

grawity
  • 501,077