[Bug 1931507] Re: rpcbind failing on 0.2.3-0.6ubuntu0.18.04.2
I came to report the bug, saw that the fix had shipped, and can confirm that it works. Thanks to Marc (and anyone in the background) for the quick response! Getting the NFS server running properly again requires either a reboot or a certain amount of tinkering; when rpcbind stops and restarts, it forgets all its rpc-program-to-IP-port mappings (they are stored only in memory). To get everything working again without rebooting, do systemctl stop nfs-server systemctl start nfs-server systemctl restart rpc-statd systemctl restart quotarpc quotarpc matters only if you use disk quotas. If you don't make sure statd is running and registered with rpcbind, both on the server and on all clients, NFS locking may not work (and processes trying to make locks may hang); this is most noticeable on a mail server. restart nfs- server should work, but when I tried it it waited forever and when interrupted left NFS down; stop/start was quick and effective. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1931507 Title: rpcbind failing on 0.2.3-0.6ubuntu0.18.04.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/1931507/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1754294] Re: After last updated libcurl3 on libcurl4, some apps are removed.
The specific package on which Shibboleth depends, and that in turn demands libcurl3, is libxmltooling7, in case that helps. And no, Adrianv, you're not the only one being hit by this! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1754294 Title: After last updated libcurl3 on libcurl4, some apps are removed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1754294/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1824433] [NEW] dhcpd ignores $CONFIG_FILE in /etc/default/isc-dhcp-server
Public bug reported:
Package isc-dhcp-server 4.3.3 on Ubuntu 16.04 LTS.
On earlier (pre-systemd) systems, one could point dhcpd at a
configuration file in any location by setting
CONFIG_FILE=/new/path/dhcpd.conf in /etc/default/isc-dhcp-server. In
this version such setting is ignored; dhcpd always uses the default
/etc/dhcp/dhcpd.conf.
In more formulaeic terms:
Put CONFIG_FILE=/var/dhcpconf/mydhcp.conf in /etc/default/isc-dhcp-server.
I expect that when service isc-dhcp-server is next started, it will use that
configuration file.
In fact it still uses /etc/dhcp/dhcpd.conf.
The problem can be worked around by making /etc/dhcp/dhcpd.conf a
symlink to the desired config file, but why have /etc/default/isc-dhcp-
server at all if it doesn't work?
The offending code is in /lib/systemd/system/isc-dhcp-server.service.
Here is a relevant extract:
[Service]
EnvironmentFile=/etc/default/isc-dhcp-server
RuntimeDirectory=dhcp-server
# The leases files need to be root:dhcpd even when dropping privileges
ExecStart=/bin/sh -ec '\
CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; fi; \
[ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid
-cf $CONFIG_FILE $INTERFACES'
/etc/default/isc-dhcp-server is correctly read as an EnvironmentFile,
but the ExecStart command unconditionally sets CONFIG_FILE, discarding
any value from the /etc/default file.
One fix might be to change the first few lines of the ExecStart to check
whether $CONFIG_FILE has been set, and perhaps whether it is still the
default value:
ExecStart=/bin/sh -ec '\
case $CONFIG_FILE in \
""|/etc/dhcp/dhcpd.conf) \
CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf;
fi; \
;; \
esac
Or it might make more sense to let whatever package is in charge of ltsp
configuration append CONFIG_FILE=/etc/ltsp/dhcpd.conf to /etc/defaults
/isc-dhcp-server, and replace the lines above with a simple
ExecStart=/bin/sh -ec '\
CONFIG_FILE=${CONFIG_FILE:-/etc/dhcp/dhcpd.conf}; \
Either way, a fix would be appreciated.
** Affects: isc-dhcp (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1824433
Title:
dhcpd ignores $CONFIG_FILE in /etc/default/isc-dhcp-server
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1824433/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1742095] Re: kernel 4.13.0-24 not working with nvidia drivers, monitor flickering
I can confirm that the by-hand fix described in #24 (add #include ' to uvm8_va_block.c) allows DKMS to compile the driver, and appears to allow both regular graphics and CUDA to work. I've taught our configuration-management system to apply the fix, but it's still a critical problem for anyone else who has an NVIDIA card and wants the Meltdown workaround. Sounds like nvidia-387 version 387.34 has the fix in place. The sooner that can become the official released version, the better. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1742095 Title: kernel 4.13.0-24 not working with nvidia drivers, monitor flickering To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742095/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1742095] Re: kernel 4.13.0-24 not working with nvidia drivers, monitor flickering
This bug also occurs in 4.13.0-26. This is a critical bug because that is now the HWE kernel for Ubuntu 16.04; we must move to it to get Meltdown fixes; but doing so makes many of our systems unusable. https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1741747 looks closely related. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1742095 Title: kernel 4.13.0-24 not working with nvidia drivers, monitor flickering To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742095/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 937602] Re: lxdm clears kerberos ticket cache on login
This problem affects us, and is quite severe: Kerberized NFS cannot work
reliably and securely with lxdm unless it is fixed. Because the
Kerberos cache is discarded, users cannot reliably get access to
Kerberos-protected home directories. The retain_after_close workaround
almost entirely bypasses Kerberos/NFS security: once someone has logged
in once, Kerberos permissions associated with their userid remain for a
long time (until their TGT expires) even after logout.
Fortunately I think I've also found a fix:
diff -cr ../lxdm-0.5.3-orig/src/pam.c ./src/pam.c
*** ../lxdm-0.5.3-orig/src/pam.c2015-07-31 08:21:09.0 -0400
--- ./src/pam.c 2017-09-08 18:29:46.0 -0400
***
*** 397,403
--- 397,405
int lxdm_auth_clean_for_child(LXDM_AUTH *a)
{
+ #if NOTDEF/*** teach.cs ***/
pam_end(a->handle,0);
+ #endif/*** teach.cs ***/
return 0;
}
lxdm calls lxdm_auth_clean_for_child between fork() (to make a new
process for the session) and exec of Xsession. Calling pam_end here
somehow calls the close_session code in pam_krb5.so, which destroys the
Kerberos ticket cache.
I don't know enough about PAM to be sure whether it's improper to call
pam_end here, or whether pam_krb5 is too eager to destroy the cache.
Pragmatically, though, removing that pam_end call makes lxdm usable.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/937602
Title:
lxdm clears kerberos ticket cache on login
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxdm/+bug/937602/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1716049] Re: bad pathnames in libpam-krb5-migrate-heimdal
Odd. At least in 16.04, package pam-krb5-migrate no longer exists, according to apt-cache search. But I'll gladly specify it! ** Package changed: ubuntu => pam-krb5-migrate (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716049 Title: bad pathnames in libpam-krb5-migrate-heimdal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam-krb5-migrate/+bug/1716049/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1716049] [NEW] bad pathnames in libpam-krb5-migrate-heimdal
Public bug reported: Ubuntu 16.04 LTS package libpam-krb5-migrate-heimdal 0.0.11-3 installs PAM module pam_krb5_migrate_heimdal.so. (Your bug-report engine claims there is no such package, and won't let me report the bug if I name it. Hogwash. See https://packages.ubuntu.com/xenial/libpam-krb5-migrate-heimdal.) It should be installed with pathname /lib/security/pam_krb5_migrate_heimdal.so, so that can be called by a PAM configuration file as pam_krb5_migrate_heimdal.so. It is actually installed with pathname /lib/security/pam_krb5_migrate_heimdal.so/pam_krb5_migrate_heimdal.so, i.e. the path that should name the .so file is actually a directory containing a file of the same name that is the real file. This smells like a simple typo somewhere in packaging, but it has the effect of making the module unusable. To reproduce: write a PAM configuration that should call pam_krb5_migrate_heimdal.so. It will fail. This should be evident in syslog, e.g. messages like PAM unable to dlopen(pam_krb5_migrate_heimdal.so): /lib/security/pam_krb5_migrate_heimdal.so: cannot read file data: Is a directory PAM adding faulty module: pam_krb5_migrate_heimdal.so Simple workaround: cd /lib/security mv pam_krb5_migrate_heimdal.so BUG mv BUG/pam_krb5_migrate_heimdal.so . ** Affects: ubuntu Importance: Undecided Status: New ** Tags: bot-comment -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716049 Title: bad pathnames in libpam-krb5-migrate-heimdal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1716049/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1693518] Re: xrdp fails if Xsession not /bin/sh script
Some additional clues: 1. The offending file in the source package, as fetched by apt-get source xrdp, is xrdp-0.6.0/debian/startwm.sh 2. I have ordinary-user access to an Ubuntu 16.04 system. apt-get source xrdp there confirms that the corresponding file xrdp-0.6.1/debian/startwm.sh is the same. So the same bug exists in Ubuntu 16.04, in xrdp 0.6.1. 3. In both cases it looks like the bug is imported from Debian. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1693518 Title: xrdp fails if Xsession not /bin/sh script To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xrdp/+bug/1693518/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1693518] [NEW] xrdp fails if Xsession not /bin/sh script
Public bug reported: In Ubuntu 14.04; package xrdp, version 0.6.0-1: If /etc/X11/Xsession is not a /bin/sh script, xrdp sessions may not start. The trouble is that /etc/xrdp/startwm.sh begins with #!/bin/sh and executes Xsession with . /etc/X11/Xsession If Xsession contains anything that is not a valid /bin/sh command, an error may result; depending on the error, Xsession may misbehave (leaving an improperly-set-up session) or just exit (abruptly terminating the session). Live example: we have a heavily-localised Xsession file. It is a bash script; its first line is #!/bin/bash It contains some commands that are valid bash but not valid /bin/sh (== dash). They are sufficiently invalid that Xsession exits. Hence no one can make a useful session via RDP. The same Xsession file has worked for years with kdm, so it is not a general assumption that Xsession is a /bin/sh script; in fact I think the general X11 rule is that it's just some sort of executable. A simple fix is to replace the offending line in startwm.sh with exec /etc/X11/Xsession (Or just /etc/X11/Xsession without the exec, but it's the last line of the file, so there's no reason to keep the extra process hanging around.) This lets the kernel decide what to do about Xsession, #!/bin/bash tells it what to do, and everything works. Thanks! ** Affects: xrdp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1693518 Title: xrdp fails if Xsession not /bin/sh script To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xrdp/+bug/1693518/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1484262] [NEW] Heimdal krb5_kuserok fails if user's home directory protected
Public bug reported: I've encountered this problem with Ubuntu 12.04.5 LTS Release: 12.04 and libkrb5-heimdal 1.6~git20120311.dfsg.1-2ubuntu0.1. It wouldn't surprise me were the problem wider in scope. Assume a valid Heimdal Kerberos setup, with: Packages heimdal-clients and libpam-heimdal installed (which also brings in sundry libraries as dependencies); /etc/krb5.conf properly set up, in particular the default realm under [libdefaults], DNS-domain-to-realm mappings under [domain_realm], and the KDC under [realms]; pam_krb5 configured in /etc/pam.d/common-auth (as should happen automatically when libpam-heimdal is installed); a proper host principal for the client host, with its key installed in /etc/krb5.keytab; and a local user with: a proper entry in /etc/passwd and /etc/shadow; a proper corresponding principal user@REALM in the KDC; a home directory accessed over NFS, with root_squash in effect. If the user's home directory has permissions 755, Kerberos login works just fine; in particular klist displays a TGT. If the user's home directory has permissions 700, Kerberos login fails. A message containing `pam_krb5(login:auth): failed authorization check' is written to syslog/auth. No session ticket cache is set up. Workaround: give pam_krb5 the ignore_k5login parameter, either in [appdefaults] in /etc/krb5.conf or whereever it appears in the several files in /etc/pam.d. I've dug around in the source, and I believe the trouble to be not in the PAM module but in the Heimdal implementation of library function krb5_kuserok. In particular, in function kuserok_user_k5login_plug_f in file lib/krb5/kuserok.c in source package heimdal-1.6~git20120311 (fetched by apt-get source libkrb5-26-heimdal). That function: a. Calls check_one_file to try to read $HOME/.k5login. If the function returns zero, the file was opened and read (and a value returned through a pointer tells whether the current principal was found); if nonzero, the value is an errno code. kuserok_user_k5login_plug_f believes that if errno was ENOENT, the file didn't exist and all is well; otherwise it acts as if it found an empty file, which means the principal wasn't listed there, which means krb5_kuserok will return failure. b. Calls check_directory to scan directory $HOME/.k5login.d. Again, it returns zero if the directory was found and opened; a nonzero errno value if not. kuserok_user_k5login_plug_f declares that all is well if the error value is ENOENT or ENOTDIR; otherwise it again causes krb5_kuserok to fail. The trouble is that when logging in, this code is executed as the super- user; hence, if the user's home directory forbids access to anyone but the owner and NFS root_squash blocks the super-user's extra permissions, check_one_file and check_directory will return EACCES, and krb5_kuserok will return failure as if .k5login existed but didn't list the current principal, and authentication will be denied. One could quibble over what to do if the file might exist but cannot be opened. (We don't know it exists because it is the directory's permissions that block access.) I've checked the MIT Kerberos source; in their rather-different krb5_kuserok implementation, any open failure for .k5login or .k5login.d allows access. That means maybe it's OK for Heimdal to do the same. On the other hand, one could argue (probably whoever wrote the code would) that it's safer to deny access if you can't tell whether the file is even there. I would argue that one of two things should happen: 1. The checks for ret == ENOENT should be changed either to ret != 0 (to match the MIT behaviour) or (ret == ENOENT || ret == EACCES) (so the permission-denied case allows access, but less-ordinary errors like EIO don't). 2. It should be documented, perhaps in the Heimdal version of pam_krb5(5), that there will be unexpected failures if the super-user is denied read permission to users' home directories, and if your system is set up that way you should use ignore_k5login. We'll probably just use ignore_k5login since for other reasons that seems the right answer for our site, but it may be a bigger problem for others. ** Affects: heimdal (Ubuntu) Importance: Undecided Status: New ** Tags: heimdal kerberos krb5 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to heimdal in Ubuntu. https://bugs.launchpad.net/bugs/1484262 Title: Heimdal krb5_kuserok fails if user's home directory protected To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1484262/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1484262] [NEW] Heimdal krb5_kuserok fails if user's home directory protected
Public bug reported: I've encountered this problem with Ubuntu 12.04.5 LTS Release: 12.04 and libkrb5-heimdal 1.6~git20120311.dfsg.1-2ubuntu0.1. It wouldn't surprise me were the problem wider in scope. Assume a valid Heimdal Kerberos setup, with: Packages heimdal-clients and libpam-heimdal installed (which also brings in sundry libraries as dependencies); /etc/krb5.conf properly set up, in particular the default realm under [libdefaults], DNS-domain-to-realm mappings under [domain_realm], and the KDC under [realms]; pam_krb5 configured in /etc/pam.d/common-auth (as should happen automatically when libpam-heimdal is installed); a proper host principal for the client host, with its key installed in /etc/krb5.keytab; and a local user with: a proper entry in /etc/passwd and /etc/shadow; a proper corresponding principal user@REALM in the KDC; a home directory accessed over NFS, with root_squash in effect. If the user's home directory has permissions 755, Kerberos login works just fine; in particular klist displays a TGT. If the user's home directory has permissions 700, Kerberos login fails. A message containing `pam_krb5(login:auth): failed authorization check' is written to syslog/auth. No session ticket cache is set up. Workaround: give pam_krb5 the ignore_k5login parameter, either in [appdefaults] in /etc/krb5.conf or whereever it appears in the several files in /etc/pam.d. I've dug around in the source, and I believe the trouble to be not in the PAM module but in the Heimdal implementation of library function krb5_kuserok. In particular, in function kuserok_user_k5login_plug_f in file lib/krb5/kuserok.c in source package heimdal-1.6~git20120311 (fetched by apt-get source libkrb5-26-heimdal). That function: a. Calls check_one_file to try to read $HOME/.k5login. If the function returns zero, the file was opened and read (and a value returned through a pointer tells whether the current principal was found); if nonzero, the value is an errno code. kuserok_user_k5login_plug_f believes that if errno was ENOENT, the file didn't exist and all is well; otherwise it acts as if it found an empty file, which means the principal wasn't listed there, which means krb5_kuserok will return failure. b. Calls check_directory to scan directory $HOME/.k5login.d. Again, it returns zero if the directory was found and opened; a nonzero errno value if not. kuserok_user_k5login_plug_f declares that all is well if the error value is ENOENT or ENOTDIR; otherwise it again causes krb5_kuserok to fail. The trouble is that when logging in, this code is executed as the super- user; hence, if the user's home directory forbids access to anyone but the owner and NFS root_squash blocks the super-user's extra permissions, check_one_file and check_directory will return EACCES, and krb5_kuserok will return failure as if .k5login existed but didn't list the current principal, and authentication will be denied. One could quibble over what to do if the file might exist but cannot be opened. (We don't know it exists because it is the directory's permissions that block access.) I've checked the MIT Kerberos source; in their rather-different krb5_kuserok implementation, any open failure for .k5login or .k5login.d allows access. That means maybe it's OK for Heimdal to do the same. On the other hand, one could argue (probably whoever wrote the code would) that it's safer to deny access if you can't tell whether the file is even there. I would argue that one of two things should happen: 1. The checks for ret == ENOENT should be changed either to ret != 0 (to match the MIT behaviour) or (ret == ENOENT || ret == EACCES) (so the permission-denied case allows access, but less-ordinary errors like EIO don't). 2. It should be documented, perhaps in the Heimdal version of pam_krb5(5), that there will be unexpected failures if the super-user is denied read permission to users' home directories, and if your system is set up that way you should use ignore_k5login. We'll probably just use ignore_k5login since for other reasons that seems the right answer for our site, but it may be a bigger problem for others. ** Affects: heimdal (Ubuntu) Importance: Undecided Status: New ** Tags: heimdal kerberos krb5 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1484262 Title: Heimdal krb5_kuserok fails if user's home directory protected To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1484262/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1479093] Re: Segfault in ld-2.19.so while starting Steam after upgrade to 3.13.0-59.98
Kernel 3.13.0-61 cures the symptoms I reported as well. Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1479093 Title: Segfault in ld-2.19.so while starting Steam after upgrade to 3.13.0-59.98 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1479093/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1479093] Re: Segfault in ld-2.19.so while starting Steam after upgrade to 3.13.0-59.98
Here is a simpler example program:
#include stdio.h
#include string.h
#include errno.h
#include unistd.h
#include sys/types.h
#include wait.h
int
main(argc, argv)
int argc;
char **argv;
{
int pid, rpid;
int st;
if (argc 2) {
fprintf(stderr, usage: %s command ...\n, argv[0]);
return (1);
}
if ((pid = fork()) 0) {
fprintf(stderr, fork: %s\n, strerror(errno));
return (1);
}
if (pid == 0) {
execvp(argv[1], argv[1]);
fprintf(stderr, exec: %s\n, strerror(errno));
return (1);
}
while ((rpid = wait(st)) 0 rpid != pid)
;
if (rpid 0) {
fprintf(stderr, wait: %s\n, strerror(errno));
return (1);
}
printf(status 0x%x\n, st);
return (0);
}
There is some header-file fumble that prevents me from compiling this
with cc -m32, but there are both 32- and 64-bit systems in our
environment, so:
Using kernel 3.13.0-59:
Compile it on a 64-bit system, and run
./forkexec date
and all is well.
Compile it on a 32-bit system, then, on a 64-bit system, run
./forkexec date
and date prints nothing, while forkexec reports exit status 0x8b.
On the other hand, still on the 64-bit system, point it at a 32-bit binary and
all is well. e.g.
./forkexec ./forkexec
just prints the expected usage: message, so it execed itself properly; no
SIGSEGV.
To confound matters further:
-- take out the fork (so the program just calls exec) and all is well
-- run the program under strace -f and the problem vanishes
All this happens under kernel 3.13.0-59 but not 3.13.0-55 (we've put off
a few updates).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1479093
Title:
Segfault in ld-2.19.so while starting Steam after upgrade to
3.13.0-59.98
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1479093/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
