https://bugzilla.novell.com/show_bug.cgi?id=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c1 --- Comment #1 from Danny van Delft 2011-11-07 23:06:17 UTC --- On the other hand, perhaps it's just a bug in /etc/rc.status: shouldn't use /dev/stderr. As a test I ran: thuis@robinia:~> echo 'echo hi there err > /dev/stderr; echo anybody home out > /dev/stdout ; echo who 2 >&2 ; echo why 1' | at 23:58 warning: commands will be executed using /bin/sh job 4 at 2011-11-07 23:58 .. waiting for 23:58 mailx Heirloom mailx version 12.5 7/5/10. Type ? for help. .. N 7 thuis@robinia.home Mon Nov 7 23:58 17/570 Output from your job 4 ? 7 Message 7: .. sh: regel 66: /dev/stderr: Toegang geweigerd sh: regel 66: /dev/stdout: Toegang geweigerd who 2 why 1 So the redirect to /dev variants don't work. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c2 Wilfred van Velzen changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium CC| |wvvelzen@gmail.com Version|Factory |Final --- Comment #2 from Wilfred van Velzen 2012-02-01 10:50:39 UTC --- It also happens after system startup, when you for instance restart mysqld ... Btw: This isn't fixed yet in the final/current 12.1 release. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c4 Ruediger Oertel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |werner@suse.com --- Comment #4 from Ruediger Oertel 2012-02-01 12:19:23 UTC --- werner, your code. can you comment on this please ? -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c6 --- Comment #6 from Frederic Crozat 2012-02-01 15:01:06 UTC --- from a quick look at initrd, /dev/stderr symlink is created there and should be available on the booting system, since /dev is moved to rootfs (/bin/mount --move /dev /root/dev ) -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c8 --- Comment #8 from Frederic Crozat 2012-02-01 15:13:13 UTC --- so, it means something is incorrectly removing the symlink from /dev .. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c10 --- Comment #10 from Wilfred van Velzen 2012-02-01 16:02:06 UTC --- Sorry this was on a 10.3 machine (I have too many open putty screens ;)) # ls -l /dev/stderr lrwxrwxrwx 1 root root 4 Jan 31 13:46 /dev/stderr -> fd/2 # ls -l /dev/fd/2 lrwx------ 1 root root 64 Feb 1 17:00 /dev/fd/2 -> /dev/pts/2 # ls -l /dev/pts/2 crw--w---- 1 root tty 136, 2 Feb 1 17:00 /dev/pts/2 -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c12 --- Comment #12 from Wilfred van Velzen 2012-02-01 17:06:54 UTC --- I can further add: /etc/init.d/mysql status or stop Doesn't trigger this behaviour. But... /etc/init.d/mysql start (or restart) does! However '/etc/init.d/mysql start' does output 'redirecting to systemctl' to stderr. So rc.status seems to be called a second time, when the error line is written to /var/log/messages, and it might be running in some chroot environment by that time? -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c14 Ruediger Oertel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ro@suse.com AssignedTo|ro@suse.com |fcrozat@suse.com --- Comment #14 from Ruediger Oertel 2012-03-19 11:45:41 UTC --- added debugging code to rc.status: + ls -l /dev/stderr /dev/fd/2 | logger which shows: Mar 19 12:43:19 fatou logger: lrwx------ 1 root root 64 Mar 19 12:43 /dev/fd/2 -> socket:[664286] Mar 19 12:43:19 fatou logger: lrwxrwxrwx 1 root root 4 Mar 7 15:53 /dev/stderr -> fd/2 Mar 19 12:43:19 fatou mysql[1753]: /etc/rc.status: line 58: /dev/stderr: No such device or address looks systemd specific. Frederic: I'm pushing this over to you for the moment ... -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c16 --- Comment #16 from Wilfred van Velzen 2012-03-19 12:28:09 UTC --- Maybe it's not fixing the underlying problem, but when you replace '>/dev/stderr' with '1>&2' on line 54 of /etc/rc.status, it's fixed! Btw: '1>&2' is used in 5 other places in /etc/rc.status, so why this single line needs to use /dev/stderr is unclear to me... -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c18 Wilfred van Velzen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |werner@suse.com --- Comment #18 from Wilfred van Velzen 2012-05-26 10:24:50 UTC --- Good question! -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c20 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |bruno@ioda-net.ch, | |dvaleev@suse.com, | |max@suse.com, | |mhrusecky@suse.com, | |mvyskocil@suse.com InfoProvider| |dvaleev@suse.com --- Comment #20 from Dr. Werner Fink 2012-05-29 08:24:00 UTC --- As it seems that the mysql boot script is destroying the symbolic link /dev/stderr I'd like to know from the current mysql maintainers which script does this do and how to fix this. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c22 --- Comment #22 from Danny van Delft 2012-05-29 08:48:53 UTC --- (In reply to comment #20)

As it seems that the mysql boot script is destroying the symbolic link /dev/stderr I'd like to know from the current mysql maintainers which script does this do and how to fix this.

As a reminder, it is not only mysql that gives this message at boot: the ntp script as well. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c25 --- Comment #25 from Dr. Werner Fink 2012-05-29 09:50:30 UTC --- (In reply to comment #22) The ntp script its self does not touch /dev/stderr that is if /dev/stderr was removed or replaced then this error simply happens to all scripts. Please note that /etc/rc.status will be sourced/readed at the very first lines of the most boot scripts. Maybe it would help to add some lines like rc_exit () test -h /dev/stderr || echo "Service $0 has removed /dev/stderr" if test -e /dev/stderr -a "$(readlink /dev/stderr)" != fd/2 ; then echo "Service $0 has destroyed /dev/stderr" fi exit $_rc_status_all } into the shell function rc_exit() of /etc/rc.status ... maybe with this we will detect the waste producer. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c27 --- Comment #27 from Danny van Delft 2012-05-29 11:52:32 UTC --- (In reply to comment #25)

(In reply to comment #22)

The ntp script its self does not touch /dev/stderr that is if /dev/stderr was removed or replaced then this error simply happens to all scripts. Please note that /etc/rc.status will be sourced/readed at the very first lines of the most boot scripts.

Maybe it would help to add some lines like

rc_exit ()

test -h /dev/stderr || echo "Service $0 has removed /dev/stderr" if test -e /dev/stderr -a "$(readlink /dev/stderr)" != fd/2 ; then echo "Service $0 has destroyed /dev/stderr" fi exit $_rc_status_all }

into the shell function rc_exit() of /etc/rc.status ... maybe with this we will detect the waste producer.

Done that, but gave no output. So added the following lines to /etc/rc.status, just before the "redirecting to systemctl" is done in the start|stop|... section: degbug="logger" echo 'OUTPUT of ls -l /dev/std*' | $degbug ls -l /dev/std* | $degbug echo 'OUTPUT of ls -lL /dev/std*' | $degbug ls -lL /dev/std* | $degbug echo 'OUTPUT of ls -l /dev/fd/*' | $degbug ls -l /dev/fd/* | $degbug echo 'OUTPUT of ls -lL /dev/fd/*' | $degbug ls -lL /dev/fd/* | $degbug echo 'OUTPUT of netstat -l -n -p' | $degbug netstat -l -n -p | $degbug echo 'OUTPUT of ps axf' | $degbug ps axf | $degbug echo "redirecting to systemctl" >/dev/stderr I will attach the output of these. In it you'll see the ultimate destination of /dev/stderr: May 29 13:36:43 postoffice logger: lrwx------ 1 root root 64 May 29 13:36 /dev/fd/2 -> socket:[8947] May 29 13:36:43 postoffice logger: OUTPUT of ls -lL /dev/fd/* May 29 13:36:43 postoffice ntp[1644]: ls: cannot access /dev/fd/3: No such file or directory May 29 13:36:43 postoffice logger: crw-rw-rw- 1 root root 1, 3 May 29 13:36 /dev/fd/0 May 29 13:36:43 postoffice logger: prw------- 1 root root 0 May 29 13:36 /dev/fd/1 May 29 13:36:43 postoffice logger: srwxrwxrwx 1 root root 0 Jan 1 1970 /dev/fd/2 A socket which apparently doesn't exist. HTH -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c29 --- Comment #29 from Danny van Delft 2012-05-29 11:56:22 UTC --- Created an attachment (id=492774) --> (http://bugzilla.novell.com/attachment.cgi?id=492774) The used rc.status from comment 27, fwiw -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c30 --- Comment #30 from Dr. Werner Fink 2012-05-29 12:09:00 UTC --- Created an attachment (id=492776) --> (http://bugzilla.novell.com/attachment.cgi?id=492776) /etc/rc.status I suggest with this script all about /dev/fd and /dev/std* will be checked and if possible it will be repaired. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c31 --- Comment #31 from Dr. Werner Fink 2012-05-29 12:22:54 UTC --- (In reply to comment #27) SysVinit does not use such sockets. Does this happen with the rc links that is with e.g. rcntp or during the boot process its self? -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c33 --- Comment #33 from Dr. Werner Fink 2012-05-29 12:49:49 UTC --- (In reply to comment #32) Guess triggered by Danny's debug session: it happens duing boot/ system start up only. And here we may have some other locations for /dev/fd and below -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c35 --- Comment #35 from Danny van Delft 2012-05-29 14:31:45 UTC --- (In reply to comment #31)

(In reply to comment #27)

SysVinit does not use such sockets. Does this happen with the rc links that is with e.g. rcntp or during the boot process its self?

Both at system boot and when manually invoking rcntp restart.

SysVinit does not use such sockets.

Fine, but this is under systemd control. So the question becomes why a symbolic link to a non existing socket is created. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c37 --- Comment #37 from Danny van Delft 2012-05-29 14:41:24 UTC --- (In reply to comment #36)

IMHO a very good question

So the question becomes why a symbolic link to a non existing socket is created.

Or probably more likely, why the socket disappears after the link has been created. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c39 --- Comment #39 from Dr. Werner Fink 2012-05-30 08:21:39 UTC --- (In reply to comment #38) Hmmm ... AFAICR a simliar problem I had with ksh which uses socketpair(2) as fast replacement for pipe(2). The major problem was and currently is that it is not possible to dup a file descriptor belonging to a socket or socketpair, whereas you can do this with file descriptors of pipes and characters devices. This was one of my reasons to use a pty/tty pair for my old blogd(8) and also this was done for startpar(8). In other words: with a socket on stdout you can not do in bash code exec 2>&1 as this will lead to an invalid file descriptor. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c41 Dieter Jurzitza changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dieter.jurzitza@t-online.de --- Comment #41 from Dieter Jurzitza 2012-06-03 12:49:55 UTC --- Hi folks, only to mention - the very same happens (I guess this is expected ...) with kernel 3.4 ... I see it with ntp, but anyway. Just to let you know, take care Dieter Jurzitza -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c43 --- Comment #43 from Jeff Mahoney 2012-06-04 11:40:22 EDT --- The mcelog issue is unrelated. No such device means that the kernel hasn't detected the device matching the device node -- not that the device node has disappeared. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c45 --- Comment #45 from Jeff Mahoney 2012-06-06 15:41:23 EDT --- BTW this can be demonstrated with the following simple program. The open statement will always fail with -ENXIO. dup() has nothing to do with it. #include #include #include #include #include #include #include #include int main(void) { int ret; int fds[2]; int fd; pid_t pid; ret = socketpair(AF_UNIX, SOCK_STREAM, 0, fds); if (ret < 0) { perror("socketpair"); return 1; } close(2); ret = dup2(fds[0], 2); if (ret < 0) { printf("dup2 failed; %d %s\n", ret, strerror(errno)); return 1; } fd = open("/dev/stderr", O_WRONLY); if (fd < 0) { printf("open failed; %d %s\n", ret, strerror(errno)); return 1; } close(fd); close(fds[0]); close(fds[1]); return 0; } -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c47 --- Comment #47 from Dr. Werner Fink 2012-06-11 12:09:52 UTC --- (In reply to comment #45) Indeed dup(2) works whereas (re)open the file (descriptor) below /proc/self/ does not. Nevertheless it seems to be common as I've a simliar bug report with the ksh which uses socketpair(2) instead of pipe(2) and this fools programs like diff (compare with bnc #627524) ... and there are more than diff which uses /proc/sef/fd/{0,1,2} or /dev/std{in,out,err} to check for standard file descriptors. The behaviour that this does not work for a socket seems to linux specific if I understand David Korn correct. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c49 --- Comment #49 from Jeff Mahoney 2012-07-09 22:27:36 EDT --- That would result in two file descriptors pointing to two struct files (like when you open the same file twice) instead of two file descriptors pointing to one struct file (like when you dup()). This is because the ->open happens with an already-allocated struct file and there's no way to pass back a different one, which is what would be required. I'll dig a little deeper for this, but it may be a limitation of the Linux VFS. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c51 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com --- Comment #51 from Ludwig Nussel 2012-09-04 15:40:38 CEST --- 12.2 still affected -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c53 Koos Pol changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koos2012@pohw.nl --- Comment #53 from Koos Pol 2012-09-24 13:37:33 UTC --- Confirmed in 12.2 x64: # service mysql start Job failed. See system journal and 'systemctl status' for details. # # tail /var/log/messages Sep 24 15:33:32 specht mysql[17057]: /etc/rc.status: line 57: /dev/stderr: No such device or address Sep 24 15:34:02 specht mysql[17057]: Starting service MySQL warning: /var/run/mysql/mysql.sock didn't appear within 30 seconds Sep 24 15:34:02 specht mysql[17057]: chmod: cannot access '/var/run/mysql/mysqld.pid': No such file or directory Sep 24 15:34:02 specht mysql[17057]: ..failed Sep 24 15:34:02 specht systemd[1]: mysql.service: control process exited, code=exited status=1 Sep 24 15:34:02 specht systemd[1]: Unit mysql.service entered failed state. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c55 Christian Boltz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manfred.h@gmx.net --- Comment #55 from Christian Boltz 2013-01-27 17:20:12 CET --- *** Bug 800573 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=800573 -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c57 --- Comment #57 from Wilfred van Velzen 2013-01-28 08:32:23 UTC --- (In reply to comment #56)

Note: Bug 800573 contains a patch - attachment 522021 [details]

The same patch has been suggested in Comment 3 of this bug almost a year ago... -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c59 --- Comment #59 from Manfred Hollstein 2013-01-28 17:14:57 UTC --- (In reply to comment #58)

(In reply to comment #57)

This is a workaround! The real problem has to be fixed otherwise the normal scripting does not work. Please note the open via `>/dev/stderr' is valid!

I'm not sure I follow you here. What do you mean with "normal scripting"? Something like ">&2" has been valid shell script code for more than 20 years and most scripters are used to it. Using "> /dev/stderr" might look more obvious, but we should make sure that the scripts work correctly, and when "> /dev/stderr" doesn't work occasionally, please open a new report for that issue in general, but lets get this particular bug fixed using a proper fix - even if you call it a workaround. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c61 Pi Ny changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piny@gmx.com --- Comment #61 from Pi Ny 2013-05-10 10:06:18 UTC --- (In reply to comment #60)

fggfgf

I confirm this bug with ntp (12.2, fresh dup from 12.1) during boot and feel tempted to repeat comment #60. It’s 15 months now since at least a workaround is known... WHY can't the workaround be implemented despite it is not THE clean solution until such a thing exists? Please don't fight on the back of your users. Now a lot of people are forced to fiddle around in a core start-up script... -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c63 --- Comment #63 from Pi Ny 2013-05-10 19:04:19 UTC --- (In reply to comment #62)

For 12,.3 and above:

Mon Feb 4 10:52:44 UTC 2013 - werner@suse.de - Avoid to stumble over missing /dev/stderr in boot script started by systemd (work around bnc#728774o but not solve it)

the question is: when this will be fixed in the kernel. I guess this will never happen as long there is not enough pressure onto the kernels people (:

I jumped forward to 12.3 and I am "Forced To Resort To Astonishment": There it is "fixed" (in terms of the workaround). -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c65 Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #65 from Jeff Mahoney 2013-09-27 10:51:20 EDT --- Closing as WONTFIX. Implementing socket dup work just to allow /dev/stderr in scripts isn't a great cost/benefit. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c67 --- Comment #67 from Jeff Mahoney 2013-10-01 14:22:46 EDT --- Created an attachment (id=561090) --> (http://bugzilla.novell.com/attachment.cgi?id=561090) [PATCH] vfs: allow /proc/pid/fd to dup a socket I've asked Miklos for his take on this patch. It could be that I'll get laughed out of the room. It at least works, though. When a process has one of the stdio file descriptors set to one end of a socket, it is prohibited from using /dev/std{in,out,err}. For example, a script that does: echo "some error" > /dev/stderr .. will get ENXIO returned. The fact that this works for nearly every other type of file except for sockets has been a source of confusion among users and developers for some time. Other UNIX-like systems don't make the distinction between socket and other files in their /dev/fd/ implementation, but this is largely due to using dup() rather than handling it as symlink-open. For a variety of reasons, the socket code depends on there being a 1:1 mapping between a struct file and struct socket. It's possible to rework the reference counting and export a few more socket functions to allow a many:1 mapping, but we use the flags associated with the file to determine if e.g. the socket is nonblocking. Having multiple files with different semantics operating on the same file would yield unexpected results. As a result, the option that's left is to dup() the existing file descriptor so that we preserve the 1:1 mapping. This is a special case that is limited to sockets opened by the current process. The symlink-open behavior has become a de-facto ABI and the dup behavior can't be used universally as it would surprise users expecting a /proc/pid/fd file open to return at offset 0 instead of the f_pos of that file descriptor. This patch adds the ability for a function in the lookup path to set a new LOOKUP_DUP_FD flag and stash the file descriptor number in the nameidata to provide the descriptor to dup after the open fails. It's hacky, but short of reworking the entire open path to accomodate this special case, it's the cleanest solution. The FreeBSD kernel reserves an int in their equivalent of task_struct for this, which is even worse. -- 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=728774 https://bugzilla.novell.com/show_bug.cgi?id=728774#c Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Kernel Version|Final |201408* Product|openSUSE 12.1 |openSUSE Factory -- 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.