You are not logged in.

#1 2013-06-04 21:00:54

EvanPurkhiser
Member
From: Akron, Ohio
Registered: 2010-08-17
Posts: 225
Website

Systemd --user, block/wait until ready for commands from systemctl?

Hey guys,

I've recently setup systemd --user for my session management.

My .profile looks like this for starting up systemd

# If systemd --user isn't running then start it up
if ! systemctl --user &> /dev/null
then
	# Double-fork the systemd process. This is done by executing a
	# sub-shell (using ()) to ensure we're not the process leader, and
	# then starting systemd using setsid to detach it from the
	# controlling tty. Finally & to fork again to the background
	(setsid /usr/lib/systemd/systemd --user --log-target=journal &)
	sleep 2
fi

# If we're logging in from VT1 then start the graphical target
if [[ $XDG_VTNR == 1 ]]
then
	systemctl --user set-environment DISPLAY=:0
	systemctl --user start graphical.target
	clear
	logout

# If we're logging in from elsewhere just start the console target
else
	systemctl --user start console.target
	source .bashrc
fi

The problem is that I have to put a sleep directly after systemd is started, if I don't then when I try and run `systemctl --user` commands it will just error out saying systemd isn't started.

Is there a command I can run directly after forking systemd to wait/block until systemd is ready to accept commands from systemctl --user?

Last edited by EvanPurkhiser (2013-06-04 21:01:29)

Offline

#2 2013-06-04 22:21:26

EvanPurkhiser
Member
From: Akron, Ohio
Registered: 2010-08-17
Posts: 225
Website

Re: Systemd --user, block/wait until ready for commands from systemctl?

This "works", but it's pretty hack-y. Still looking for suggestions

# Wait for systemd to be ready to accept connections
while ! systemctl --user &> /dev/null; do
	sleep 0.1
done

Offline

#3 2013-06-05 00:10:21

EvanPurkhiser
Member
From: Akron, Ohio
Registered: 2010-08-17
Posts: 225
Website

Re: Systemd --user, block/wait until ready for commands from systemctl?

I've come up with a little better solution.

I can watch the $XDG_RUNTIME_DIR and wait for systemd to create the 'systemd/private' socket. Once it creates that socket it's ready for connections

So I can do

# If systemd --user isn't running then start it up
if ! systemctl --user &> /dev/null
then
	# Double-fork the systemd process. This is done by executing a
	# sub-shell (using ()) to ensure we're not the process leader, and
	# then starting systemd using setsid to detach it from the
	# controlling tty. Finally & to fork again to the background
	(setsid /usr/lib/systemd/systemd --user --log-target=journal &)

	# Wait for systemd socket directory to be created
	inotifywait -t 3 -e create "$XDG_RUNTIME_DIR" &> /dev/null
fi

The downside to this is I had to install the inotify-tools package.

Still looking for any better suggestions.

Edit: I'm actually running into a race-condition with this, where systemd creates the socket file faster than inotifywait can start watching. If I check if the file exists first the race condition may still occur.

Last edited by EvanPurkhiser (2013-06-05 01:04:18)

Offline

#4 2014-04-20 03:39:05

EvanPurkhiser
Member
From: Akron, Ohio
Registered: 2010-08-17
Posts: 225
Website

Re: Systemd --user, block/wait until ready for commands from systemctl?

An updated on this! Stebalien has written a nice little tool called 'systemd-wait' that does something very close to this. Doesn't exactly solve the specific topic, but might be helpful to others.

Offline

Board footer

Powered by FluxBB