https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c2 --- Comment #2 from Gerald Pfeifer 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c3 Frederic Crozat changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lmuelle@suse.com --- Comment #3 from Frederic Crozat 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c5 --- Comment #5 from Frederic Crozat 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c7 Thomas Hänig changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |haenig@cosifan.de --- Comment #7 from Thomas Hänig 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c9 --- Comment #9 from Frederic Crozat 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) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c11 --- Comment #11 from Frederic Crozat 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.. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c13 --- Comment #13 from Marius Tomaschewski 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c15 Frederic Crozat 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 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=747783 https://bugzilla.novell.com/show_bug.cgi?id=747783#c17 Frederic Crozat changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #17 from Frederic Crozat 2013-11-21 13:52:50 UTC --- closing as fixed for 13.1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.