https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c2

--- Comment #2 from Gerald Pfeifer gp@suse.com 2012-02-21 20:12:09 CET --- Yes, the active terminal works just as expected. It's the spamming of all the others that is the issue.

https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c3

Frederic Crozat fcrozat@suse.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |lmuelle@suse.com

--- Comment #3 from Frederic Crozat fcrozat@suse.com 2012-03-30 12:04:13 UTC --- *** Bug 754952 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=754952

https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c5

--- Comment #5 from Frederic Crozat fcrozat@suse.com 2012-07-25 07:43:08 UTC --- I've discussed this bug with upstream and it is very tricky to get it fixed because the password prompt is asynchronous to the request and you could also get several query at the same time.

Excerpt from IRC discussion: juin 25 13:45:05 <fcrozat> mezcalero: while I have a grab on you, a quick question. systemd-tty-ask-password-agent "wall" on all tty, even when you are on the terminal where the request is originating (and you have the prompt). Would it be ok if I (try to) cook a patch to make sure it "walls" only when active tty isn't the one where the prompt is running ? juin 25 15:47:50 <mezcalero> fcrozat: hmm, actually we have a logic in there that avoids the active tty juin 25 15:47:57 <mezcalero> fcrozat: must be broken for you i guess? juin 25 15:48:06 <mezcalero> fcrozat: oh juin 25 15:48:07 <mezcalero> hmm juin 25 15:48:17 <mezcalero> nah, different thing juin 25 15:48:22 <fcrozat> mezcalero: ah, ok ;) juin 25 15:48:28 <mezcalero> or hmmm juin 25 15:48:45 * mezcalero needs to look up what i hacked there juin 25 15:49:09 <fcrozat> :) juin 25 15:51:18 <mezcalero> fcrozat: hmm, so wall_tty_block() in tty-ask-password-agent.c should already do what you are asking for? juin 25 15:51:26 <mezcalero> fcrozat: it uses fifos as locks juin 25 15:53:03 <fcrozat> mezcalero: well, it doesn't (or something isn't). See https://bugzilla.novell.com/show_bug.cgi?id=747783 for bug report juin 25 15:53:19 <fcrozat> (I plugged openvpn to use tty-ask-password) juin 25 15:53:24 <mezcalero> fcrozat: hmm, so the code flow might be surprising juin 25 15:53:38 <mezcalero> fcrozat: but basically in systemctl we spawn into the background on instance of thy agent juin 25 15:53:48 <mezcalero> another instance of the agent is run for the wall stuff juin 25 15:54:54 <fcrozat> but could we prevent the wall instance to start if we are on the active terminal ? Does this behaviour would be acceptable for you ? juin 25 15:55:22 <mezcalero> right now the tty instance blocks out the other juin 25 15:55:37 <mezcalero> by creating creating a lock for that tty in question juin 25 15:55:43 <mezcalero> the wall instance will honour that lock juin 25 15:55:49 <mezcalero> and not display the message on that screen juin 25 15:56:05 <mezcalero> but what i do wonder about now is whether there might be a race here juin 25 15:56:23 <mezcalero> i.e. that the wall instance runs quicker and doesn't see the tty lock juin 25 15:57:00 <fcrozat> well, it does work juin 25 15:57:05 <mezcalero> it does? juin 25 15:57:05 <fcrozat> it doesn't wall on the active terminal juin 25 15:57:11 <fcrozat> it wall on all others :) juin 25 15:57:20 <mezcalero> hmm, so, what's the question? juin 25 15:57:43 <fcrozat> could we prevent to wall on all others, if we are in the active terminal when the fifo was started ? juin 25 15:58:10 <mezcalero> uh juin 25 15:58:16 <mezcalero> well, there is a bit of a problem there juin 25 15:58:42 <mezcalero> there is no way to figure out whether a question is being asked due to the local tty juin 25 15:59:15 <mezcalero> i.e. if somebody plugs in a usb key that is encrypted at the same time as you type "systemctl start somethingelse.service" and both need a passowrd juin 25 15:59:23 <mezcalero> then i assume you'd one wall to show, and the other now juin 25 15:59:24 <mezcalero> not juin 25 16:00:00 <mezcalero> but the thing is that we really have no information about which UI action actually triggered a password being needed juin 25 16:00:07 <mezcalero> resp. whether there was any UI action at all juin 25 16:00:21 <mezcalero> for example, it might just be your iscsi server being powered on juin 25 16:00:25 <mezcalero> and things like this juin 25 16:00:36 <fcrozat> specially since I'm using this stuff for openvpn credentials too :) juin 25 16:00:42 <mezcalero> so, there is really no clear chain of events, that we could rely on and use to hide some walls, and show the others juin 25 16:00:48 <fcrozat> (I got two bug reports from the same guy, one for crypsetup, one for openvpn ;) juin 25 16:01:08 <mezcalero> i mean, at least i know no nice way to do this... juin 25 16:01:33 <mezcalero> maybe the best suggestion is to ask him to use "systemctl mask" on the wall agent? juin 25 16:01:58 <fcrozat> well, seems a ugly workaround for an "ugly" behaviour (from a usability perspective) ;) juin 25 16:02:15 <mezcalero> well, i mean, i am open to ideas on this juin 25 16:02:24 <mezcalero> if you figure out a nice way, i am all ears juin 25 16:02:29 <mezcalero> but i see no nice way juin 25 16:03:37 <fcrozat> well, if we can differentiate stuff coming from a event from a "started from a service by user", we would have a way

https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c7

Thomas Hänig haenig@cosifan.de changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |haenig@cosifan.de

--- Comment #7 from Thomas Hänig haenig@cosifan.de 2012-11-13 12:14:53 UTC --- SCNR, but such things happen if one breaks 'one program for one task' with each and everything becoming service/server/systemwide.

What speaks against e.g. openvpn running on ist own?

My "solution", because I'm the one and only user (OpenSuSE 12.2, openvpn 2.2.2): # echo > /usr/bin/wall

https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c9

--- Comment #9 from Frederic Crozat fcrozat@suse.com 2013-02-11 17:34:29 UTC --- (In reply to comment #8)

Any news on this?

no and it is really not very high in my todo list (moreover, since upstream doesn't see a solution for it)

https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c11

--- Comment #11 from Frederic Crozat fcrozat@suse.com 2013-02-12 10:23:44 UTC --- try "systemctl mask systemd-ask-password-wall.service" as root

it will prevent the wall service for asking password to start..

https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c13

--- Comment #13 from Marius Tomaschewski mt@suse.com 2013-05-08 09:26:37 UTC --- When it is started at boot time, systemd tools are used and they broadcast/wall. You can provide the username / password using systemd-tty-ask-password-agent.

To avoid the wall messages, you can set OPENVPN_AUTOSTART=" " in /etc/sysconfig/openvpn to avoid automatic starts and start the configs later manually using

"rcopenvpn [re]start xyz"

to start /etc/openvpn/xyz.conf. Then openvpn starts directly (no systemd redirection to systemctl), asks on the console only (and joins openvpn.service cgroup, so "status" shows it later].

This is IMO the only workaround we can provide here.

BTW: On factory all is done using systemd mechanisms, the init script and variable are gone, use:

systemctl enable openvpn@xyz.service

and then e.g.:

systemctl [re]start openvpn@xyz.service

or also:

systemctl [re]start openvpn.target

to start all configs. When called manually, prompt is on console. Otherwise you can provide it via systemd-tty-ask-password-agent.

https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c15

Frederic Crozat fcrozat@suse.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Component|Basesystem |YaST2 AssignedTo|fcrozat@suse.com |bnc-team-screening@forge.pr | |ovo.novell.com QAContact|qa-bugs@suse.de |jsrain@suse.com

--- Comment #15 from Frederic Crozat fcrozat@suse.com 2013-10-01 16:55:38 UTC --- ok, I was able to reproduce the issue in a VM.

YaST2-Second-Stage.service (and FirstBoot.service) should have: cryptsetup.target added to their After= line.

This will ensure all YaST* services will be started after cryptsetup is being handled (I thought the dependency on local-fs.target was enough, but apparently, it isn't).

I would also suggest to add this dependency to Factory too.

https://bugzilla.novell.com/show_bug.cgi?id=747783

https://bugzilla.novell.com/show_bug.cgi?id=747783#c17

Frederic Crozat fcrozat@suse.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED

--- Comment #17 from Frederic Crozat fcrozat@suse.com 2013-11-21 13:52:50 UTC --- closing as fixed for 13.1