Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

graysky · 2015-09-04 23:07:17

How can I have query systemd to see if a user service is running in a post_install script (which pacman will run as root)? This is straightforward for system services:

systemctl is-enabled foo.service

But for user services, how can I query all user services that are running and the see if foo.service is running for any and all users?

Last edited by graysky (2015-09-06 11:59:54)

Trilby · 2015-09-04 23:25:45

Why would you want to do this? You could do some variation of `find /home/*/.config/systemd ...` instead, but I can't imagine a case in which any such query would be a good idea.

WorMzy · 2015-09-04 23:27:42

I would recommend that you leave user services alone. I would also recommend that you leave system services alone.

If a user/system service should be reloaded/restarted post-upgrade, you should alert the user in a postinstall message. It is the end-user's responsibility to restart these services, not the package's.

graysky · 2015-09-04 23:30:12

Well, if the service needs to be stopped before pacman removes executable, a message to the user would be too late.

Trilby · 2015-09-04 23:55:17

Trilby wrote:

Why would you want to do this?

Is the executable target being renamed? Would the executable already be running, or is is run periodically on a timer? Give us a hint here.

If the executable target is being renamed, perhaps you could use a symlink for a transitional version for a while where the old executable name would link to the new executable. But this might also be nonsense as you haven't clarified what actually needs to change.

mauritiusdadd · 2015-09-05 07:28:35

graysky wrote:

Well, if the service needs to be stopped before pacman removes executable, a message to the user would be too late.

This sounds like an X-Y problem: as Trilby already asked, why the service needs to be stopped? If something changes in the service file, usually executing systemctl --user daemon-reload should be enough. Maybe It's because you need ExecStop to be run before the installation? However...

graysky wrote:

How can I have query systemd to see if a user service is running in a post_install script (which pacman will run as root)?

since you need to stop the service before pacman removes the executable (that means the package is already installed), you could put this in the pre_upgrade() function:

# NOTE: you can use systemctl --user only if the user is logged in
#            that's why we use $(users) here

for x in $(users); do
  enabled="$(su $x -c 'systemctl --user is-enabled gpg-agent')"
  if [[ "$enabled" == "enabled" ]]; then
    # do somthing here, for example
    # su $x -c 'systemctl --user stop foo.service'
  fi
done

but this approach has several drawbacks:

It's ugly
There is no easy way to keep track of which user had the service running, so you can't restart the service just for them in post_upgrade() and you will have to alert the user in a postinstall message anyway (maybe you can save a list of users in a tempfile, but it's even more ugly)
Users don't expect their services to be started/stopped by others, especially by pacman

--edit: typo

Last edited by mauritiusdadd (2015-09-05 07:29:18)

graysky · 2015-09-05 10:10:50

Trilby wrote:

Is the executable target being renamed? Would the executable already be running, or is is run periodically on a timer? Give us a hint here.

I am only talking about if the user wants to remove the package. In this case, the executable would be getting removed by pacman. So in this case, it needs to be called to run a clean-up function before it is removed from the system.

mauritiusdadd wrote:

# NOTE: you can use systemctl --user only if the user is logged in
#            that's why we use $(users) here

for x in $(users); do
  enabled="$(su $x -c 'systemctl --user is-enabled gpg-agent')"
  if [[ "$enabled" == "enabled" ]]; then
    # do somthing here, for example
    # su $x -c 'systemctl --user stop foo.service'
  fi
done

I came up with a similar code snippet. Just to clarify, I don't think using it in the pre_upgrade is right, just in the pre_remove since this would only need to be called if the package were to be removed.

mauritiusdadd wrote:

but this approach has several drawbacks:
It's ugly
There is no easy way to keep track of which user had the service running, so you can't restart the service just for them in post_upgrade() and you will have to alert the user in a postinstall message anyway (maybe you can save a list of users in a tempfile, but it's even more ugly)
Users don't expect their services to be started/stopped by others, especially by pacman

point #1) Yes.
point #2) I don't know how to figure out which users on the system could be running it, i.e. how to define the contents of $(users) in your code in a general fashion such that the scriptlet could auto populate it based on any generic system.
point #3) Yes, I agree with this as well but again, cannot think of an alternative.

EDIT: Maybe the following would work to populate $(user):

users=$(getent passwd | grep home | awk -F: '{print $1}' | awk 1 ORS=' ')

Last edited by graysky (2015-09-05 10:36:23)

graysky · 2015-09-05 10:39:52

@mauritiusdadd - Nope, the script fails when executed by root:

% cat test 
#!/bin/sh
users=$(getent passwd | grep home | awk -F: '{print $1}' | awk 1 ORS=' ')
echo $user
for i in $users; do
 running="$(su $x -c 'systemctl --user is-active psd')"
 if [[ "$running" = "active" ]]; then
  echo $i is running it
 fi
done

% sudo su
# ./test
Failed to get D-Bus connection: No such file or directory
Failed to get D-Bus connection: No such file or directory

Last edited by graysky (2015-09-05 10:51:17)

mauritiusdadd · 2015-09-05 11:00:35

graysky wrote:

@mauritiusdadd - Nope, the script fails when executed by root:
users=$(getent passwd | grep home | awk -F: '{print $1}' | awk 1 ORS=' ')

It's because in your code ${users} is a variable containing also users which has not logged in. In the code I posted, the for loop was based on the output of the program users (note the round brackets) which shows only the name of the users already logged in. You can ignore users not logged in because their user services are not running,

graysky · 2015-09-05 11:03:30

mauritiusdadd wrote:

It's because in your code ${users} is a variable containing also users which has not logged in. In the code I posted, the for loop was based on the output of the program users (note the round brackets) which shows only the name of the users already logged in. You can ignore users not logged in because their user services are not running,

Ah! Didn't know about /usr/bin/users which is more simplistic. But substituting it still yields the same dbus connection errors when run as root

Trilby · 2015-09-05 11:12:35

graysky wrote:

I am only talking about if the user wants to remove the package. In this case, the executable would be getting removed by pacman. So in this case, it needs to be called to run a clean-up function before it is removed from the system.

Why? What needs to be cleaned up? No other package "cleans up" files in a user's home directory when its package is removed. What is unique about your case such that this would be called for.

mauritiusdadd · 2015-09-05 11:27:18

graysky wrote:

Ah! Didn't know about /usr/bin/users which is more simplistic. But substituting it still yields the same dbus connection errors when run as root

It seems that you use $i as variable for the for loop, but you are passing $x (which is empty) to su

for i in $users; do
 running="$(su $x -c 'systemctl --user is-active psd')"

Last edited by mauritiusdadd (2015-09-05 11:27:51)

graysky · 2015-09-05 11:37:00

Trilby wrote:

graysky wrote:
I am only talking about if the user wants to remove the package. In this case, the executable would be getting removed by pacman. So in this case, it needs to be called to run a clean-up function before it is removed from the system.
Why? What needs to be cleaned up? No other package "cleans up" files in a user's home directory when its package is removed. What is unique about your case such that this would be called for.

https://aur.archlinux.org/packages/profile-sync-daemon

Symlinks a directory to tmpfs. If removed before the unsync, it will leave a broken symlink on the filesystem and a renamed profile.

graysky · 2015-09-05 11:53:07

@mar - that was a typo. If you run the code on your system as root do you get the same dubs errors?

mauritiusdadd · 2015-09-05 12:15:33

It works fine on both my desktop and my laptop: I tested it by adding a coulpe of users and then I tested it also in a clean chroot... what happens if you run the following code? Is there a user with a broken dbus session?

#!/bin/sh
for i in $(users); do
 echo "---[$i]---"
 su $i -c 'env | grep DBUS'
 running="$(su $i -c 'systemctl --user is-active psd')"
 if [[ "$running" = "active" ]]; then
  echo $i is running it
 else
  echo $i is not running it
 fi
done

on my machine it outputs

---[daddona]---
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-GBmTt3wzt0,guid=9ef2acf2b3c851fcfc97382155ead6c7
daddona is not running it
---[user1]---
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-GBmTt3wzt0,guid=9ef2acf2b3c851fcfc97382155ead6c7
user1 is not running it
---[user2]---
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-GBmTt3wzt0,guid=9ef2acf2b3c851fcfc97382155ead6c7
user2 is not running it
---[user3]---
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-GBmTt3wzt0,guid=9ef2acf2b3c851fcfc97382155ead6c7
user3 is not running it

--edit: typo

Last edited by mauritiusdadd (2015-09-05 14:17:17)

graysky · 2015-09-05 18:55:17

Didn't work for me either in a clean chroot or out.

% sudo ./test
---[facade]---
Failed to get D-Bus connection: No such file or directory
facade is not running it
---[facade]---
Failed to get D-Bus connection: No such file or directory
facade is not running it

EDIT: I also tried running it on 2 other machines and was met with the same results

Last edited by graysky (2015-09-05 19:24:39)

mauritiusdadd · 2015-09-06 08:15:16

Ok, I was running the script using su but using sudo I was able to reproduce the problem: it seems that systemctl --user needs to access the user's $XDG_RUNTIME_DIR. The problem is that this environment variable is set by systemd-logind at login trough the module pam_systemd, but this module is not loaded when using su or sudo, so $XDG_RUNTIME_DIR is not available in the environment of the target user. Therefore, the only option left is to set the variable in the script: according to the pam_systemd documentation, the default value for the runtime directory is /run/user/$USER so this should work

#!/bin/sh
for i in $(users); do
  echo "---[$i]---"
  running="$(su $i -c 'XDG_RUNTIME_DIR=/run/user/$UID systemctl --user is-active psd')"
  if [[ "$running" = "active" ]]; then
    echo $i is running it
  else
    echo $i is not running it
  fi
done

It will however fail if a user have set a different runtime directory (is this even possible using systemd-logind?) other than the default one

Last edited by mauritiusdadd (2015-09-06 08:16:22)

graysky · 2015-09-06 11:59:17

Nice! Thank you! Defining the XDG_RUNTIME_DIR was the key.

pre_remove() {
 for i in $(users); do
  running="$(su $i -c 'XDG_RUNTIME_DIR=/run/user/$UID systemctl --user is-active psd')"
   if [[ "$running" = "active" ]]; then
    echo "--> In order to preserve your profiles, pacman will now stop your psd service."
    echo "--> Any running and managed browsers will be exited."
    su $i -c 'XDG_RUNTIME_DIR=/run/user/$UID systemctl --user stop psd.service'
   fi
  done
}

Last edited by graysky (2015-09-06 12:27:26)

Arch Linux

#1 2015-09-04 23:07:17

Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#2 2015-09-04 23:25:45

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#3 2015-09-04 23:27:42

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#4 2015-09-04 23:30:12

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#5 2015-09-04 23:55:17

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#6 2015-09-05 07:28:35

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#7 2015-09-05 10:10:50

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#8 2015-09-05 10:39:52

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#9 2015-09-05 11:00:35

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#10 2015-09-05 11:03:30

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#11 2015-09-05 11:12:35

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#12 2015-09-05 11:27:18

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#13 2015-09-05 11:37:00

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#14 2015-09-05 11:53:07

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#15 2015-09-05 12:15:33

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#16 2015-09-05 18:55:17

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#17 2015-09-06 08:15:16

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

#18 2015-09-06 11:59:17

Re: Query systemd --user mode in a pre_remove for PKGBUILD [SOLVED]

Board footer