More than half of the Debian archive has been compiled successfully on the Hurd, however, many programs fail to build for various reasons.
A list of build failures including error messages can be found, as well as a preliminary analysis of them and solutions, and some more details in guidelines. Graphs and statistics about the consequence in terms of build dependencies are available.
There is a mailing list, debian-hurd-build-logs, where builds logs from the Debian GNU/Hurd autobuilders are posted. It is a high-traffic and high-volume list, and for that reason not archived, so you have to subscribe to see the messages.
It might be a good idea to record your intention to port something either in the list below or in the Alioth task tracker so other people do not do duplicated work.
Also, the ?HurdFr guys maintain their own liste des travaux de packaging.
Aside from the Alioth task tracker, here is a list of some packages (the important ones, as they're, e.g., blocking other packages from being built) that need someone to work on them.
When you have a patch to submit, please adhere to the patch submission guidelines.
There is also further information available about porting.
- hurd
-
open issues
- Upstart
- adduser: posix_spawn() error=1073741826
- bash
- boehm gc
- elinks
- GNU Emacs
- fakeroot eagain
- fcntl.*F_SETFL.*FD_.*
- Hiccups of Git
- git duplicated content
- git nfs mmap
- increasing bogus port at boot
- libc variant selection
- libtool
- m4 vs stack
- netstat
- prelink
- pth
- runit
- sbcl
- screen
- screen dead session
- socat
- ssh
- systemd
- ti-rpc then nfs
- time
- tmux
- wayland
- wine
- X.Org Porting
- user
When the ntpdate package is installed, one gets at boot something like:
Debian GNU/Hurd stretch/sid debian console
task ext2fs increasing a bogus port 947 by 1, most probably a bug.
task ext2fs increasing a bogus port 947 by 1, most probably a bug.
task ext2fs deallocating a bogus port 947, most probably a bug.
task ext2fs deallocating a bogus port 947, most probably a bug.
login:
This is coming from the execution of the shell script /etc/network/if-up.d/ntpdate, whose stdout/stderr is on the Mach console, but part of which gets executed after getty starts on it. It happens that getty uses revoke() to revoke access to it from other programs, and thus the ntpdate shell scripts gets its stdout/stderr in a bogus state, which libc doesn't really cope with correctly.
Commenting c:23:respawn:/sbin/getty 38400 console from /etc/inittab works
around the issue (but removes the getty from the Mach console)
Upstart is an event based init system that is GPL licensed, however upstream contributions are under a CLA that permits proprietary relicensing.
As of Jan 2 2013, Debian is considering adopting Upstart as an init system on GNU/Linux, and on GNU/kFreeBSD when the port to kFreeBSD is finished.
The following are the words of Colin Watson on the debian-ctte@lists.debian.org mailing list and list the requirements of a potential HURD port:
I haven't looked at this in much detail, and I suspect Dimitri hasn't yet although IIRC he did express some interest in doing so. But I haven't seen anyone else try to outline the scope of a port, so let me try to do so for the sake of general understanding. As far as I know, the hardest parts would be inotify, ptrace, and prctl (PR_SET_CHILD_SUBREAPER).
inotify is used to notice changes to configuration files. This is certainly helpful for users, but it isn't critical as "initctl reload-configuration" works without it. We could probably do without this with the aid of a dpkg trigger.
ptrace is used for "expect fork" and "expect daemon"; as I indicated in another post, I think it would be preferable to avoid these in Debian and quite possibly to compile them out. (This would mean we wouldn't be able to translate Ubuntu jobs quite as directly, and a number of important jobs would definitely need to be changed, but the conversion isn't usually particularly difficult.)
prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work properly when Upstart is supervising a user session. This isn't a required feature and could easily be compiled out until suitable kernel support is available (this actually seems like the sort of thing that could be done in the Hurd without too much difficulty, but I haven't looked into it). If absent, it might well impede the ability to do an advanced desktop port, but it wouldn't get in the way of porting the bulk of services.
There might also be odds and ends around the details of wait status handling.
inotify seems to be a feature that is often used in GNU/Linux programs, and implementing the feature in the HURD seems like a better and more rewarding option than porting the code in Upstart.
Although many daemons double fork, that behavior seems to be dying out, and one can comfortably ignore the "expect fork/daemon" functionality of Upstart (and compile it out).
See also the discussion about upstart on the systemd page.
IRC, freenode, #hurd, 2013-08-01
<braunr> teythoon: can you stop tmux on darnassus please ?
<braunr> i'd like to check something
<teythoon> done
<braunr> tmux makes load average grow to 5 without any visible activity :/
<braunr> can't reproduce it with my instances though
<braunr> anyway, that's minor
<teythoon> I used tmux before and never encountered that
<teythoon> sometimes tmux would hang on attaching or detaching though, but
overall I had less problems with tmux than with screen
<teythoon> ah, I tried to start tmux on darnassus and now it hangs
IRC, freenode, #hurd, 2014-02-04
<teythoon> braunr: whoa, i can reproduce gnu_srs' hanging ssh sessions on
darnassus
<teythoon> here goes
<teythoon> run tmux, exit the shell so that tmux quits, start tmux again
(tmux hangs now on some socket stuff), log in with ssh again, pkill tmux,
rm /tmp/tmux*/default => both ssh sessions hang and time out eventually
<braunr> why start tmux twice ?
<teythoon> dunno
<teythoon> that's what i just did, twice in a row
<teythoon> there's a bug somewhere that makes tmux hang if the socket
exists but no tmux server is running
<teythoon> maybe that contributes to to the other issuse, i don't know
<braunr> looks like an infinite loop somewhere
<gnu_srs> teythoon: Nice to set that I'm not alone having this problem:P
<braunr> teythoon: what's happening ? :)
<teythoon> ?
<braunr> on darnassus
<teythoon> not sure
<teythoon> uh, something is very wrong o_O
<teythoon> help ?
<braunr> :)
<braunr> the msg thread of a process is blocked somewhere
<braunr> preventing ps/top from completing
<braunr> looks like proc is blocked now ..
<braunr> restarting the vm
<braunr> apparently, removing buggy tmux sockets make pflocal crash
<braunr> thanks for the report :)
<teythoon> you are welcome :)
Ssh compression does not work at the server level for some reason:
Jul 2 18:06:08 debian sshd[405]: fatal: buffer_uncompress: inflate returned -3
One has to disable compression in /etc/sshd_config:
Compression no
The error returned by inflate is Z_DATA_ERROR.
IRC, OFTC, #debian-hurd, 2012-12-16
<pinotree> http://lists.debian.org/<50CE505F.3040106@pyro.eu.org>
<pinotree> or http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679198#123
too
<youpi> ouch, there are quite a few!
<pinotree> most are "duplicated", like the source in webkit2 copies (so
fixing it once upstream will make it fixed progressively once the copies
are upgraded)
<youpi> ah, ok
<pinotree> similar for ruby 1.8/1.9/jruby
IRC, freenode, #hurd, 2012-12-05
<braunr> rbraun 18813 R 2hrs ln -sf ../af_ZA/LC_NUMERIC
debian/locales-all/usr/lib/locale/en_BW/LC_NUMERIC
<braunr> when building glibc
<braunr> is this a known issue ?
<tschwinge> braunr: No. Can you get a backtrace?
<braunr> tschwinge: with gdb you mean ?
<tschwinge> Yes. If you have any debugging symbols (glibc?).
<braunr> or the build log leading to that ?
<braunr> ok, i will next time i have it
<tschwinge> OK.
<braunr> (i regularly had it when working on the pthreads port)
<braunr> tschwinge:
http://www.sceen.net/~rbraun/hurd_glibc_build_deadlock_trace
<braunr> youpi: ^
<youpi> Mmm, there's not so much we can do about this one
<braunr> youpi: what do you mean ?
<youpi> the problem is that it's really a reentrency issue of the libc
locale
<youpi> it would happen just the same on linux
<braunr> sure
<braunr> but hat doesn't mean we can't report and/or fix it :)
<youpi> (the _nl_state_lock)
<braunr> do you have any workaround in mind ?
<youpi> no
<youpi> actually that's what I meant by "there's not so much we can do
about this"
<braunr> ok
<youpi> because it's a bad interaction between libfakeroot and glibc
<youpi> glibc believe fxtstat64 would never call locale functions
<youpi> but with libfakeroot it does
<braunr> i see
<youpi> only because we get an EAGAIN here
<braunr> but hm, doesn't it happen on linux ?
<youpi> EAGAIN doesn't happen on linux for fxstat64, no :)
<braunr> why does it happen on the hurd ?
<youpi> I mean for fakeroot stuff
<youpi> probably because fakeroot uses socket functions
<youpi> for which we probably don't properly handleEAGAIN
<youpi> I've already seen such kind of issue
<youpi> in buildd failures
<braunr> ok
<youpi> (so the actual bug here is EAGAIN
<youpi> )
<braunr> yes, so we can do something about it
<braunr> worth a look
<pinotree> (implement sysv semaphores)
<youpi> pinotree: if we could also solve all these buildd EAGAIN issues
that'd be nice :)
<braunr> that EAGAIN error might also be what makes exim behave badly and
loop forever
<youpi> possibly
<braunr> i've updated the trace with debugging symbols
<braunr> it fails on connect
<pinotree> like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563342 ?
<braunr> it's EAGAIN, not ECONNREFUSED
<pinotree> ah ok
<braunr> might be an error in tcp_v4_get_port
IRC, freenode, #hurd, 2012-12-06
<braunr> hmm, tcp_v4_get_port sometimes fails indeed
<gnu_srs> braunr: may I ask how you found out, adding print statements in
pfinet, or?
<braunr> yes
<gnu_srs> OK, so that's the only (easy) way to debug.
<braunr> that's the last resort
<braunr> gdb is easy too
<braunr> i could have added a breakpoint too
<braunr> but i didn't want to block pfinet while i was away
<braunr> is it possible to force the use of fakeroot-tcp on linux ?
<braunr> the problem seems to be that fakeroot doesn't close the sockets
that it connected to faked-tcp
<braunr> which, at some point, exhauts the port space
<pinotree> braunr: sure
<pinotree> change the fakeroot dpkg alternative
<braunr> ok
<pinotree> calling it explicitly `fakeroot-tcp command` or
`dpkg-buildpackage -rfakeroot-tcp ...` should work too
<braunr> fakeroot-tcp looks really evil :p
<braunr> hum, i don't see any faked-tcp process on linux :/
<pinotree> not even with `fakeroot-tcp bash -c "sleep 10"`?
<braunr> pinotree: now yes
<braunr> but, does it mean faked-tcp is started for *each* process loading
fakeroot-tcp ?
<braunr> (the lib i mean)
<pinotree> i think so
<braunr> well the hurd doesn't seem to do that at all
<braunr> or maybe it does and i don't see it
<braunr> the stale faked-tcp processes could be those that failed something
only
<pinotree> yes, there's also that issue: sometimes there are stake
faked-tcp processes
<braunr> hum no, i see one faked-tcp that consumes cpu when building glibc
<pinotree> *stale
<braunr> it's the same process for all commands
<pinotree> <braunr> but, does it mean faked-tcp is started for *each*
process loading fakeroot-tcp ?
<pinotree> → everytime you start fakeroot, there's a new faked-xxx for it
<braunr> it doesn't look that way
<braunr> again, on the hurd, i see one faked-tcp, consuming cpu while
building so i assume it services libfakeroot-tcp requests
<pinotree> yes
<braunr> which means i probably won't reproduce the problem on linux
<pinotree> it serves that fakeroot under which the binary(-arch) target is
run
<braunr> or perhaps it's the normal fakeroot-tcp behaviour on sid
<braunr> pinotree: a faked-tcp that is started for each command invocation
will implicitely make the network stack close all its sockets when
exiting
<braunr> pinotree: as our fakeroot-tcp uses the same instance of faked-tcp,
it's a lot more likely to exhaust the port space
<pinotree> i see
<braunr> i'll try on sid and see how it behaves
<braunr> pinotree: on the other hand, forking so many processes at each
command invocation may make exec leak a lot :p
<braunr> or rather, a lot more
<braunr> (or maybe not, since it leaks only in some cases)
<braunr> pinotree: actually, the behaviour under linux is the same with the
alternative correctly set, whereas faked-tcp is restarted (if used at
all) with -rfakeroot-tcp
<braunr> hm no, even that isn't true
<braunr> grr
<braunr> pinotree: i think i found a handy workaround for fakeroot
<braunr> pinotree: the range of local ports in our networking stack is a
lot more limited than what is configured in current systems
<braunr> by extending it, i can now build glibc \o/
<pinotree> braunr: what are the current ours and the usual one?
<braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c
<braunr> the modern ones are the ones suggested in the comment
<braunr> sysctl_local_port_range is the symbol storing the range
<pinotree> i see
<pinotree> what's the current range on linux?
<braunr> 20:44 < braunr> the modern ones are the ones suggested in the
comment
<pinotree> i see
<braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range
<braunr> 32768 61000
<braunr> so, i'm not sure why we have the problem, since even on linux,
netstat doesn't show open bound ports, but it does help
<braunr> the fact faked-tcp can remain after its use is more problematic
<pinotree> (maybe pfinet could grow a (startup-only?) option to change it,
similar to that sysctl)
<braunr> but it can also stems from the same issue gnu_srs found about
closed sockets that haven't been shut down
<braunr> perhaps
<braunr> but i don't see the point actually
<braunr> we could simply change the values in the code
<braunr> youpi: first, in pfinet, i increased the range of local ports to
reduce the likeliness of port space exhaustion
<braunr> so we should get a lot less EAGAIN after that
<braunr> (i've not committed any of those changes)
<youpi> range of local ports?
<braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c, tcp_v4_get_port function
and sysctl_local_port_range array
<youpi> oh
<braunr> EAGAIN is caused by tcp_v4_get_port failing at
<braunr> /* Exhausted local port range during search? */
<braunr> if (remaining <= 0)
<braunr> goto fail;
<youpi> interesting
<youpi> so it's not a hurd bug after all
<youpi> just a problem in fakeroot eating a lot of ports
<braunr> maybe because of the same issue gnu_srs worked on (bad socket
close when no clean shutdown)
<braunr> maybe, maybe not
<braunr> but increasing the range is effective
<braunr> and i compared with what linux does today, which is exactly what
is in the comment above sysctl_local_port_range
<braunr> so it looks safe
<youpi> so that means that the pfinet just uses ports 1024- 4999 for
auto-allocated ports?
<braunr> i guess so
<youpi> the linux pfinet I meant
<braunr> i haven't checked the whole code but it looks that way
<youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_min[] = { 1, 1
};
<youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_max[] = { 65535,
65535 };
<youpi> looks like they have increased it since then :)
<braunr> hum :)
<braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range
<braunr> 32768 61000
<youpi> yep, same here
<youpi> ./inet_connection_sock.c: .range = { 32768, 61000 },
<youpi> so there are two things apparently
<youpi> but linux now defaults to 32k-61k
<youpi> braunr: please just push the port range upgrade to 32Ki-61K
<braunr> ok, will do
<youpi> there's not reason not to do it
IRC, freenode, #hurd, 2012-12-11
<braunr> youpi: at least, i haven't had any failure building eglibc since
the port range patch
<youpi> good :)
IRC, freenode, #hurd, 2012-12-06
<braunr> we need a netstat command
<pinotree> wouldn't that require rpcs and notifications in pfinet to get
info on the known sockets?
<braunr> depends on the interface
<braunr> netstat currently uses /proc/net/* so that's out of the question
<braunr> but a bsd netstat using ioctls could do the job
<braunr> i'm not sure if it's done that way
<braunr> i don't see why it would require notifications though
<pinotree> if add such rpcs to pfinet, you could show the sockets in procfs
<braunr> yes
<braunr> that's the clean way :p
<braunr> but why notifications ?
<pinotree> to get changes on data of sockets (status change, i/o activity,
etc)
<pinotree> (possibly i'm forgetting some already there features to know
that)
<braunr> the socket state is centralized in pfinet
<braunr> netstat polls it
<braunr> (or asks it once)
IRC, freenode, #hurd, 2012-03-18:
<antrik> Wayland should be very portable. all the system dependencies are
in the infrastructure, such as DRI
<antrik> we have had a DRI task (for X.Org) for years
<antrik> (in fact I would be the right person to implement this,
considering my background -- by quite frankly, I doubt I'll ever do it)
<tschwinge> http://xorg.freedesktop.org/wiki/Hurd_Porting
IRC, freenode, #hurd, 2012-03-20:
<youlysses> Is wayland something that will be semi-easy to port to the
hurd? I saw GNOME is heading in this direction.
<pinotree> wayland at the moment is linux only
<tschwinge> youlysses: A DRI implementation will be needed.
<pinotree> that, and libdrm compiling
<youlysses> So it will take some work ... but theres no *HUGE* design
decison that would inhibit it?
<pinotree> i know it uses epoll, for instance
<tschwinge> youlysses: I cannot judge how complex a DRI system is, and how
much needs to be designed vs. implemented.
See the list of Hurd-related X.Org project ideas.
GCC: libtool: finish: ldconfig is not run for the Hurd.
This probably comes from libtool's libltdl/m4/libtool.m4 (or similar):
finish_cmds.
There are a few other differences between gnu and linux* | k*bsd*-gnu |
kopensolaris*-gnu.
gphoto2
The gphoto2 digital camera command-line client.
Home page: http://www.gphoto.org/proj/libgphoto2
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Only one file relies on PATH_MAX: gphoto2/main.c
First need to patch libgphoto2 package.
Comments
Not yet started.
libgphoto2
ImpulseTracker clone aiming at providing the same look&feel.
Home page: http://www.gphoto.org/proj/libgphoto2
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Fix gphoto2-settings.c:gp_setting_get() to accept NULL pointer and do the allocation.
This is a requirement for gphoto2 patch.
Comments
Not yet started.
pidgin-microblog
Microblogging plugins for Pidgin.
Home page: http://code.google.com/p/microblog-purple/
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX pidgin-microblog-0.3.0/*:
pidgin-microblog-0.3.0/microblog/mb_cache.c:static char cache_base_dir[PATH_MAX] = "";
pidgin-microblog-0.3.0/microblog/mb_cache.c:snprintf(cache_base_dir, PATH_MAX, "%s/mbpurple", user_dir);
The cache_base_dir is static but should only be called through a getter.
If it has not been initialized, return "" from the getter.
Comments
Not yet started.
schism
ImpulseTracker clone aiming at providing the same look&feel.
Home page: http://nimh.org/schismtracker
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX schism-0+20110101/*:
include/disko.h: char tempname[PATH_MAX];
include/disko.h: char filename[PATH_MAX];
include/headers.h:# undef PATH_MAX
schism/disko.c: if (len + 6 >= PATH_MAX) {
schism/audio_loadsave.c:char song_filename[PATH_MAX + 1];
schism/audio_loadsave.c: strncpy(song_filename, file, PATH_MAX);
schism/audio_loadsave.c: song_filename[PATH_MAX] = '\0';
schism/page_loadmodule.c:static char filename_entry[PATH_MAX + 1] = "";
schism/page_loadmodule.c:static char dirname_entry[PATH_MAX + 1] = "";
schism/page_loadmodule.c:char cfg_module_pattern[PATH_MAX + 1] = GLOB_DEFAULT;
schism/page_loadmodule.c:static char glob_list_src[PATH_MAX + 1] = ""; // the pattern used to make glob_list (this is an icky hack)
schism/page_loadmodule.c: strncpy(glob_list_src, globspec, PATH_MAX);
schism/page_loadmodule.c: glob_list_src[PATH_MAX] = '\0';
schism/page_loadmodule.c: strncpy(cfg_dir_modules, ptr, PATH_MAX);
schism/page_loadmodule.c: cfg_dir_modules[PATH_MAX] = 0;
schism/page_loadmodule.c: create_textentry(widgets_loadmodule + 2, 13, 46, 64, 0, 3, 3, NULL, filename_entry, PATH_MAX);
schism/page_loadmodule.c: create_textentry(widgets_loadmodule + 3, 13, 47, 64, 2, 3, 0, NULL, dirname_entry, PATH_MAX);
schism/page_loadmodule.c: create_textentry(widgets_exportsave + 2, 13, 46, 64, 0, 3, 3, NULL, filename_entry, PATH_MAX);
schism/page_loadmodule.c: create_textentry(widgets_exportsave + 3, 13, 47, 64, 2, 0, 0, NULL, dirname_entry, PATH_MAX);
schism/util.c: char buf[PATH_MAX];
schism/util.c: if (strlen(filename) > PATH_MAX - 16) {
schism/util.c: char buf[PATH_MAX + 1];
schism/util.c: if (getcwd(buf, PATH_MAX))
schism/util.c: char buf[PATH_MAX + 1];
schism/util.c: if (getcwd(buf, PATH_MAX))
schism/util.c: char buf[PATH_MAX + 1];
schism/util.c: char buf[PATH_MAX];
schism/util.c: char buf2[PATH_MAX];
schism/util.c: if (!GetCurrentDirectory(PATH_MAX-1,buf)) return 0;
schism/util.c: snprintf(buf2, PATH_MAX-2, "%s.bat", name);
schism/main.c: strncpy(cfg_dir_modules, initial_dir, PATH_MAX);
schism/main.c: cfg_dir_modules[PATH_MAX] = 0;
schism/main.c: strncpy(cfg_dir_samples, initial_dir, PATH_MAX);
schism/main.c: cfg_dir_samples[PATH_MAX] = 0;
schism/main.c: strncpy(cfg_dir_instruments, initial_dir, PATH_MAX);
schism/main.c: cfg_dir_instruments[PATH_MAX] = 0;
schism/page_loadinst.c:static char inst_cwd[PATH_MAX+1] = "";
schism/page_loadinst.c:static char slash_search_str[PATH_MAX];
schism/page_loadinst.c: strncpy(cfg_dir_instruments, ptr, PATH_MAX);
schism/page_loadinst.c: cfg_dir_instruments[PATH_MAX] = 0;
schism/page_loadinst.c: strncpy(inst_cwd, ptr, PATH_MAX);
schism/page_loadinst.c: inst_cwd[PATH_MAX] = 0;
schism/page_loadinst.c: if (slash_search_mode < PATH_MAX) {
schism/config.c:char cfg_dir_modules[PATH_MAX + 1], cfg_dir_samples[PATH_MAX + 1], cfg_dir_instruments[PATH_MAX + 1],
schism/config.c: cfg_dir_dotschism[PATH_MAX + 1], cfg_font[NAME_MAX + 1];
schism/config.c: strncpy(cfg_dir_dotschism, ptr, PATH_MAX);
schism/config.c: cfg_dir_dotschism[PATH_MAX] = 0;
schism/config.c: cfg_get_string(&cfg, "Directories", "modules", cfg_dir_modules, PATH_MAX, tmp);
schism/config.c: cfg_get_string(&cfg, "Directories", "samples", cfg_dir_samples, PATH_MAX, tmp);
schism/config.c: cfg_get_string(&cfg, "Directories", "instruments", cfg_dir_instruments, PATH_MAX, tmp);
schism/config.c: strncpy(cfg_module_pattern, ptr, PATH_MAX);
schism/config.c: cfg_module_pattern[PATH_MAX] = 0;
schism/page_vars.c: cfg_dir_modules, PATH_MAX);
schism/page_vars.c: cfg_dir_samples, PATH_MAX);
schism/page_vars.c: cfg_dir_instruments, PATH_MAX);
schism/page_loadsample.c:static char current_filename[PATH_MAX];
schism/page_loadsample.c:static char search_str[PATH_MAX];
schism/page_loadsample.c: PATH_MAX-1);
schism/page_loadsample.c: PATH_MAX-1);
schism/page_loadsample.c: strncpy(cfg_dir_samples, ptr, PATH_MAX);
schism/page_loadsample.c: cfg_dir_samples[PATH_MAX] = 0;
schism/page_loadsample.c: if (search_pos < PATH_MAX) {
Comments
Not yet started.
Looks like a lot, but most of them, if not all, are trivial.
shush
Runs a command and optionally reports its output by mail.
Home page: http://web.taranis.org/shush
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX shush-1.2.3/*:
src/shush.c: char cfdir[PATH_MAX+1], *slfac, *to[3];
src/shush.c: strlcpy(cfdir+1, optarg, PATH_MAX);
src/shush.c: snprintf(cfdir+1, PATH_MAX, "%s/.shush", getenv("HOME"));
src/crontab.c: static char cfname[PATH_MAX];
src/crontab.c: snprintf(cfname, PATH_MAX, "%s/schedule", cfdname);
src/crontab.c: snprintf(cfname, PATH_MAX, "%s/%s", cfdname, token);
src/crontab.c: snprintf(cfname, PATH_MAX, "%s/%s", cfdname, entry->d_name);
src/crontab.c: char tag[PATH_MAX+80], *oldtab, *mytab, newtab[PATH_MAX];
src/crontab.c: snprintf(newtab, PATH_MAX, "%s/%s-crontab.XXXXXX",
src/state.c:static char statepath[PATH_MAX];
src/state.c: snprintf(statepath, PATH_MAX, "%s/.state/shtate-%lu-%s-%s-%u",
src/state.c: snprintf(statepath, PATH_MAX, "%s/shtate-%lu-%s-%s-%u",
src/run.c: char fname[PATH_MAX], outlog[PATH_MAX], errlog[PATH_MAX], *outstr, *errstr;
src/run.c: snprintf(fname, PATH_MAX, "%s/%s", cfdir, job);
src/run.c: snprintf(outlog, PATH_MAX, "%s.stdout", cf_getstr(CF_CONFIG));
src/run.c: snprintf(errlog, PATH_MAX, "%s.stderr", cf_getstr(CF_CONFIG));
src/run.c: snprintf(fname, PATH_MAX, "%s/.%s-%s", cfdir, jid, get_hostname(0));
src/run.c: snprintf(outlog, PATH_MAX, "%s/%s-%s.stdout.XXXXXX",
src/run.c: snprintf(errlog, PATH_MAX, "%s/%s-%s.stderr.XXXXXX",
src/check.c: char fname[PATH_MAX], outre[PATH_MAX], errre[PATH_MAX], *outstr, *errstr;
src/check.c: snprintf(fname, PATH_MAX, "%s/%s", cfdir, job);
src/check.c: snprintf(outre, PATH_MAX, "%s.stdout", cf_getstr(CF_CONFIG));
src/check.c: snprintf(errre, PATH_MAX, "%s.stderr", cf_getstr(CF_CONFIG));
Comments
Not yet started.
sitecopy
A program for managing a WWW site via FTP, DAV or HTTP.
Home page: http://www.manyfish.co.uk/sitecopy
Log
- Started: -
- Discussed: -
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX sitecopy-0.16.6/*:
intl/dcigettext.c: PATH_MAX but might cause redefinition warnings when sys/param.h is
intl/dcigettext.c:#ifndef _POSIX_PATH_MAX
intl/dcigettext.c:# define _POSIX_PATH_MAX 255
intl/dcigettext.c:#if !defined PATH_MAX && defined _PC_PATH_MAX
intl/dcigettext.c:# define PATH_MAX (pathconf ("/", _PC_PATH_MAX) < 1 ? 1024 : pathconf ("/", _PC_PATH_MAX))
intl/dcigettext.c:#if defined HAVE_SYS_PARAM_H && !defined PATH_MAX && !defined MAXPATHLEN
intl/dcigettext.c:#if !defined PATH_MAX && defined MAXPATHLEN
intl/dcigettext.c:# define PATH_MAX MAXPATHLEN
intl/dcigettext.c:#ifndef PATH_MAX
intl/dcigettext.c:# define PATH_MAX _POSIX_PATH_MAX
intl/dcigettext.c: path_max = (unsigned int) PATH_MAX;
src/ftp.c:#include <limits.h> /* for PATH_MAX */
src/ftp.c:#ifndef PATH_MAX
src/ftp.c:#define PATH_MAX 2048
src/ftp.c: char cwd[PATH_MAX];
src/ftp.c: char dir[PATH_MAX];
src/ftp.c: if (!sess->use_cwd || fn[0] != '/' || strlen(fn) > PATH_MAX)
debian/patches/10_bts410703_preserve_storage_files_sigint.dpatch:+ char filebuf[PATH_MAX];
debian/patches/10_bts410703_preserve_storage_files_sigint.dpatch:+ char filebuf[PATH_MAX];
Comments
Not yet started.
One of the PATH_MAX if used in debian patch.
sakura
Simple but powerful libvte-based terminal emulator.
Home page: http://www.pleyades.net/david/sakura.php
Log
- Started: 2012-02-03
- Discussed: 2012-02-03
- Draft Submitted: -
- Submitted: 2012-02-07, Bug#659018
- Accepted: 2012-02-12, by Andrew Starr-Bochicchio
ToDo
Here is the output of grep -R PATH_MAX sakura-2.4.2/*:
src/sakura.c: char buf[PATH_MAX+1];
Comments
+ char *buf = NULL;
+ struct stat sb;
Will dynamically allocate the buffer according to information provided by lstat().
+ if (lstat(file, &sb) == -1) {
+ return cwd;
+ }
+ buf = malloc(sb.st_size + 1);
Do the allocation. Don't bother to check for return value as g_strdup_printf() doesn't do it.
+ len = readlink (file, buf, sb.st_size + 1);
+ if (len < 0 || len > sb.st_size) {
+ g_free(buf);
+ return cwd;
+ }
Check realink() return value.
+ g_free(buf);
Free the dynamically allocated buffer.
auto-apt
When you want to build a program from source and it fails due to missing headers. Auto-apt can search what package would provide the header files.
(from https://help.ubuntu.com/community/AutoApt)
Log
- Started: 2012-01-24
- Discussed: 2012-01-26
- Draft Submitted: -
- Submitted: 2012-02-07, Bug#659025
- Accepted: 2013-05-13, by Barry deFreese
ToDo
The output of grep -R PATH_MAX auto-apt-0.3.22/* is a bit long. It contains files that have been patched using #define PATH_MAX XYZ.
Here is the only file of interest:
pkgcdb/pkgtab.c: char buf[PATH_MAX];
pkgcdb/pkgtab.c: assert(p - pkg < PATH_MAX);
pkgcdb/pkgtab.c: static char buf[PATH_MAX];
pkgcdb/pkgtab.c: assert(len < PATH_MAX);
Comments
+++ auto-apt-0.3.22/auto-apt-pkgcdb.c 2012-02-03 09:25:54.045858173 +0100
+ unsigned char *buf = NULL;
+ while (!feof(stdin)) {
unsigned char *fname, *pkg;
unsigned char *p;
int nslash = 0;
+ buf = get_line(stdin);
+ if (buf == NULL)
+ break;
Reading from stdin using the get_line() function as explained in the porting guide.
+ free(buf);
+++ auto-apt-0.3.22/pkgcdb/pkgtab.c 2012-01-30 09:05:07.883096049 +0100
+ char *buf = NULL;
+ buf = (char *)malloc(p - pkg + 1);
+ if (buf == NULL) {
+ abort();
+ }
+ free(buf);
- static char buf[PATH_MAX];
+ static char *buf;
+ if (buf != NULL) {
+ free(buf);
+ }
+ buf = (char *)malloc(len + 1);
+ if (buf == NULL) {
+ abort();
+ }
rng-tools
Daemon to use a Hardware TRNG. The rngd daemon acts as a bridge between a Hardware TRNG (true random number generator) such as the ones in some Intel/AMD/VIA chipsets, and the kernel's PRNG (pseudo-random number generator).
(from http://packages.debian.org/lenny/rng-tools)
Log
- Started: 2012-01-28
- Discussed: 2012-01-30
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX rng-tools-2-unofficial-mt.14/*:
viapadlock_engine.c:static char cpudev_path[PATH_MAX+1];
viapadlock_engine.c:char devpath[PATH_MAX+1];
Comments
Work in progress, see related thread.
Even if the PATH_MAX can be easily fixed, some problems remain.
The code uses linux/types.h, that has to be replaced by sys/types.h, but also uses linux/random.h which has no equivalent I know of.
At least one source file is named after the OS: rngd_linux.c.
up-imapproxy
SquirrelMail's IMAP Proxy is a caching IMAP proxy server intended for use with webmail clients that cannot maintain persistent connections to an IMAP server.
Home page: http://www.imapproxy.org
Log
- Started: 2012-01-31
- Discussed: 2012-02-03
- Draft Submitted: -
- Submitted: -
- Accepted: -
ToDo
Here is the output of grep -R PATH_MAX up-imapproxy-1.2.7/*:
src/main.c: char f_randfile[ PATH_MAX ];
Comments
Work in progress...
Only the function that fills the buffer knows how long it can be.
This function is RAND_file_name() and is part of OpenSSL.
Probably OpenSSL function has to be fixed first to accept NULL buffer.
Then fix the up-imapproxy code to use the new version of the function.
TI-RPC replaces glibc's Sun RPC implementation, id:"4D0632C5.1040107@RedHat.com".
It needs some work on our side, id:"20101214213212.GU1095@kepler.schwinge.homeip.net".
Then, the Hurd's nfs translator and ?nfsd can be
re-enabled, id:"87hb2j7ha7.fsf@gnu.org".
IRC, freenode, #hurd, 2014-02-19
<pere> hi. I'm trying to port libtirpc to get rcpbind on hurd, and am
unable to find IPV6_PORTRANGE and IPV6_PORTRANGE_LOW. is this a known
problem with a known fix?
<braunr> what are they supposed to be ?
<pere> braunr: found them described in <URL:
http://www.daemon-systems.org/man/ip6.4.html >.
<braunr> "The IPV6_PORTRANGE socket option and the conflict resolution rule
are not defined in the RFCs and should be considered implementation
dependent
<braunr> "
<braunr> hm
<braunr> if we have that, they're very probably not accessible from outside
our network stack
<pere> needed feature on hurd, in other words...
<braunr> why ?
<pere> If I remember correctly, SO_PEERCRED is also missing?
<braunr> yes ..
<braunr> that one is important
<pere> braunr: you wonder why the IPV6_PORTRANGE socket option was created?
<braunr> i wonder why it's needed
<braunr> does linux have it ?
<pere> yes, linux got it.
<braunr> same name ?
<pere> it make it possible for some services to work with some
firewalls. :)
<pere> yes, same name, as far I can tell.
<braunr> they could merely bind ports explicitely, couldn't they ?
<pere> not always.
<braunr> or is it for servers on creation of a client socket ?
<pere> see <URL:
http://www.stacken.kth.se/lists/heimdal-discuss/2000-11/msg00002.html >
for an example I came across.
<braunr> i don't find these macros on linux :/
<pere> how strange. libtirpc build on linux.
<braunr> is there a gitweb or so somewhere ?
<braunr> i can't find it on sf :/
<pere> for <URL: http://sourceforge.net/projects/libtirpc >, you mean?
<braunr> yes
<pere> no idea.
<braunr> are you looking at upstream 0.2.4 or a particular debian package ?
<pere> I'm looking at the debian package.
<braunr> let me take a look
<pere> http://paste.debian.net/82971/ is my first draft patch to get the
source building.
<braunr> ok so
<braunr> in src/bindresvport.c
<braunr> if you look carefully, you'll see that these _PORTRANGE macros are
used in non linux code
<braunr> not very portable but it explains why you hit the problem
<braunr> try using #if defined (__linux__) || defined(__GNU__)
<braunr> also, i think we intend to implement SCM_CREDS, not SO_PEERCRED
<braunr> but consider we have neither for now
<pere> ah, definitely a simpler fix.
<braunr> pere: btw, see
https://lists.debian.org/debian-hurd/2010/12/msg00014.html
<pere> <URL: https://bugs.debian.org/739557 > with patch reporte.d
IRC, freenode, #hurd, 2014-02-20
<pere> new libtirpc with hurd fixes just uploaded to debian. should fix
the rpcbind build too.
IRC, OFTC, #debian-hurd, 2014-02-20
<pere> hm, rpcbind built with freshly patched libtirpc fail to work on
hurd. no idea why.
<pere> running 'rpcinfo -p' show 'rpcinfo: can't contact portmapper: RPC:
Success'
<teythoon> o_O
<pere> I have no idea how to debug it. :(
<pere> anyway, I've found that rpcinfo is the broken part. rpcbind work,
when I test it from a remote machine.
IRC, OFTC, #debian-hurd, 2014-02-21
<pere> failing rpcinfo -p on hurd reported as <URL:
http://bugs.debian.org/739674 >. Anyone got a clue how to debug it?
IRC, OFTC, #debian-hurd, 2014-03-03
<pere> I was just tipped by sesse that the hurd fix for libtirpc probably
caused RC bug in nfs-common, <URL: https://bugs.debian.org/740491 >.
Have not had time to check it out more closely.
IRC, OFTC, #debian-hurd, 2014-03-04
<youpi> pere: I don't really see how debian/patches/05-hurd-port.diff could
break Linux' libtirpc
<youpi> AIUI, the patch has zero effect on non-hurd builds
<youpi> oh wait
<youpi> it's simply missing a reautoconf to get HAVE_SYS_USER_H undefined
in config.h.in
<pere> youpi: I am quite sure I did add the required dh_autoreconf call.
did you see a build log where it was missing?
<youpi> pere: ah, ok. Then 02-rerun-bootstrap.diff can be dropped
<youpi> and I don't have any further idea
<youpi> pere: maybe it's the autoreconf itself which broke something?
<pere> could be. not quite sure how to find out.
<gnu_srs> pere: what about running autoreconf on the previous (working
version)?
<pere> gnu_srs: sound like a good idea. perhaps a good idea to just
disable the two patches as a start.
IRC, freenode, #hurd, 2011-08-12
< zyg> did the segment registers had any purpose? I see fs is set equal to
others, but on linux fs is 0 (atleast on this x86 box).
< braunr> zyg: it can be used by special applications like wine, yes
< zyg> braunr: thanks.. I'm reading up on linux actually. It seems gs can
be used for TLS, fs in syscall to pass userspace.
< braunr> zyg: why are you interested in that ?
< zyg> a native compiler under linux places assumptions on fs register. So
I'm trying to find out what it should do under gnumach/hurd.
< braunr> what compiler ?
< zyg> braunr: it's sbcl
< braunr> ok
< youpi> zyg: the same, basically
< zyg> ok.. looking at the code, I've remarked where it sets up FS, because
/usr/include/asm/ldt.h:struct user_desc is missing. I must search for the
equiv.
< youpi> zyg: mach/i386/mach_i386.h
< youpi> the descriptor structure
Debian's openjdk-7-jre package depends on libaccess-bridge-java-jni (source package: java-access-bridge).
The latter one has openjdk-6-jdk as a build dependency, but that can be hacked around:
# ln -s java-7-openjdk /usr/lib/jvm/java-6-openjdk
Trying to build it:
$ LD_LIBRARY_PATH=/usr/lib/jvm/java-7-openjdk/jre/lib/i386/jli dpkg-buildpackage -b -uc -d
[...]
make[3]: Entering directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen'
/usr/lib/jvm/java-6-openjdk/bin/idlj \
-pkgPrefix Bonobo org.GNOME \
-pkgPrefix Accessibility org.GNOME \
-emitAll -i /usr/share/idl/bonobo-activation-2.0 -i /usr/share/idl/at-spi-1.0 -i /usr/share/idl/bonobo-2.0 \
-fallTie /usr/share/idl/at-spi-1.0/Accessibility.idl
/usr/share/idl/at-spi-1.0/Accessibility_Collection.idl (line 66): WARNING: Identifier `object' collides with a keyword; use an escaped identifier to ensure future compatibility.
boolean isAncestorOf (in Accessible object);
^
/usr/share/idl/at-spi-1.0/Accessibility_Component.idl (line 83): WARNING: Identifier `Component' collides with a keyword; use an escaped identifier to ensure future compatibility.
interface Component : Bonobo::Unknown {
^
Exception in thread "main" java.lang.AssertionError: Platform not recognized
at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:71)
at java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:108)
at java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(FileSystems.java:89)
at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:98)
at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:96)
at java.security.AccessController.doPrivileged(Native Method)
at java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:95)
at java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.java:90)
at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:489)
at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:480)
at java.security.AccessController.doPrivileged(Native Method)
at sun.util.calendar.ZoneInfoFile.<clinit>(ZoneInfoFile.java:479)
at sun.util.calendar.ZoneInfo.getTimeZone(ZoneInfo.java:658)
at java.util.TimeZone.getTimeZone(TimeZone.java:559)
at java.util.TimeZone.setDefaultZone(TimeZone.java:656)
at java.util.TimeZone.getDefaultRef(TimeZone.java:623)
at java.util.TimeZone.getDefault(TimeZone.java:610)
at java.text.SimpleDateFormat.initializeCalendar(SimpleDateFormat.java:682)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:619)
at java.text.DateFormat.get(DateFormat.java:772)
at java.text.DateFormat.getDateTimeInstance(DateFormat.java:547)
at com.sun.tools.corba.se.idl.toJavaPortable.Util.writeProlog(Util.java:1139)
at com.sun.tools.corba.se.idl.toJavaPortable.Skeleton.writeHeading(Skeleton.java:145)
at com.sun.tools.corba.se.idl.toJavaPortable.Skeleton.generate(Skeleton.java:102)
at com.sun.tools.corba.se.idl.toJavaPortable.InterfaceGen.generateSkeleton(InterfaceGen.java:159)
at com.sun.tools.corba.se.idl.toJavaPortable.InterfaceGen.generate(InterfaceGen.java:108)
at com.sun.tools.corba.se.idl.InterfaceEntry.generate(InterfaceEntry.java:110)
at com.sun.tools.corba.se.idl.toJavaPortable.ModuleGen.generate(ModuleGen.java:75)
at com.sun.tools.corba.se.idl.ModuleEntry.generate(ModuleEntry.java:83)
at com.sun.tools.corba.se.idl.Compile.generate(Compile.java:324)
at com.sun.tools.corba.se.idl.toJavaPortable.Compile.start(Compile.java:169)
at com.sun.tools.corba.se.idl.toJavaPortable.Compile.main(Compile.java:146)
make[3]: *** [org/GNOME/Accessibility/Accessible.java] Error 1
make[3]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
IRC, freenode, #hurd, 2011-08-10:
< jkoenig> and with my latest fix (hardwire os.name as "Linux"),
java-access-bridge actually built \o/
< youpi> I wouldn't call it a "fix" :)
< jkoenig> true, but pretty much everything assumes we're either solaris,
linux or windows :-/
< jkoenig> also we're actually using the Linux code which it is used to
select throughout the JDK
< jkoenig> if it's any consolation, os.version stays "GNU-Mach
1.3.99/Hurd-0.3" :-)
< youpi> ideally it should simply be changed to "GNU"
The prelink package, as distributed via Debian unstable, does build on
GNU/Hurd. After installing the satisfiable dependencies, use
dpkg-buildpackage -b -uc -d to ignore SELinux and libc6-dev dependencies.
It is unclear whether it also does work. The testsuite (run manually) does
FAIL on all tests, which is due to the prelinker doing something to the
copied ld.so.1 so that it faults on every invocation. This does not happen
on GNU/Linux.
Not much in the prelinker is Linux-specific. src/get.c's is_ldso_soname
should already cover our ld.so.1 case (and what about ld.so?). At the end
of src/arch-i386.c, .dynamic_linker has to be set properly. And, in that
file there are some Linux process VM constants, of which REG2S and REG2E
are the only relevant in the !exec_shield case. Probably these need to be
adjusted. What else?
$ git-new-workdir ~/tmp/binutils/git /media/hd1s1/tmp/master master
error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call)
Checking out files: 100% (12315/12315), done.
Already on 'master'
$ cd /media/hd1s1/tmp/master
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout -f
$ git status
# On branch master
nothing to commit (working directory clean)
(Git issue is known.)
$ git-new-workdir ~/tmp/binutils/git /media/hd1s2/tmp/master master
error: unable to create file bfd/elf32-dlx.c (Interrupted system call)
error: unable to create file bfd/sunos.c (Interrupted system call)
error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call)
error: unable to create file gas/testsuite/gas/mmix/regx-op.d (Interrupted system call)
error: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (Interrupted system call)
error: unable to create file gold/testsuite/script_test_2.t (Interrupted system call)
error: unable to create file ld/testsuite/ld-mmix/loc7m.d (Interrupted system call)
error: unable to create file ld/testsuite/ld-powerpc/tlsexe.g (Interrupted system call)
Checking out files: 100% (12315/12315), done.
Already on 'master'
$ cd /media/hd1s2/tmp/master
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: bfd/elf32-dlx.c
# modified: bfd/sunos.c
# modified: gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d
# modified: gas/testsuite/gas/mmix/regx-op.d
# modified: gas/testsuite/gas/tic6x/reloc-bad-4.s
# modified: gold/testsuite/script_test_2.t
# modified: ld/testsuite/ld-mmix/loc7m.d
# modified: ld/testsuite/ld-powerpc/tlsexe.g
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout -f
$ git status
# On branch master
nothing to commit (working directory clean)
Now you'd expect these directories to have identical content, but:
$ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff
$ ls -l /tmp/diff
-rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff
$ grep '^[^ @+-]' < /tmp/diff
diff -x .git -ru /media/hd1s1/tmp/master//ld/configure /media/hd1s2/tmp/master//ld/configure
(Note that this isn't a file that Git had issues with.)
Try again:
$ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff_
$ ls -l /tmp/diff*
-rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff
-rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_
$ cmp /tmp/diff{,_}; echo $?
0
At least it's consistent. Force a reload:
# settrans -ag /media/hd1s1
# settrans -ag /media/hd1s2
Try again:
$ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff__
$ ls -l /tmp/diff*
-rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff
-rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_
-rw-r--r-- 1 thomas thomas 613677 10. Jun 19:30 /tmp/diff__
$ cmp /tmp/diff{,__}; echo $?
0
Consistent; thus very likely corrupt on-disk.
After a few tries, the pattern generally is that for the files where there are differences, once the file regularely ends, its content appears once more. That is, the files' content appears once (regularely), and then the same again.
Some more copying:
$ (cd /media/hd1s1/tmp/ && cp -a master master_)
$ (cd /media/hd1s2/tmp/ && cp -a master master_)
$ diff -x .git -ru /media/hd1s1/tmp/master{,_}/ > /tmp/diff1
$ diff -x .git -ru /media/hd1s2/tmp/master{,_}/ > /tmp/diff2
$ ls -l /tmp/diff{1,2}
-rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff1
-rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff2
No further difference.
$ git-new-workdir git master master
$ diff -x .git -ur tar_master/ master/ > master.diff
$ rm -rf ar_master* && (cd git/ && git archive master) | (mkdir ar_master && cd ar_master/ && tar -x) && diff -x .git -ru tar_master/ ar_master/ > ar_master.diff; ls -l ar_master.diff
$ (cd git/ && git archive master) | md5sum
2011-06-13
-> git-core-2
$ git-new-workdir /media/kepler-data/home/thomas/tmp/source/binutils/git master master
fatal: Out of memory? mmap failed: No such device
$ echo $?
128
$ showtrans /media/kepler-data
/hurd/nfs kepler.schwinge.homeip.net:/media/data
With sh -x:
[...]
+ ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/remotes master/.git/remotes
+ ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/rr-cache master/.git/rr-cache
+ ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/svn master/.git/svn
+ cd master
+ cp /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/HEAD .git/HEAD
+ git checkout -f master
fatal: Out of memory? mmap failed: No such device
As one can easily guess (and confirm with rpctrace), git
tries to mmap a file via the nfs translator, this
fails, and it isn't prepared to cope with that:
[...]
88->dir_lookup (".git/objects/pack/pack-37ca560e7877fa0cc6e5ddcd556aa73e5a3e3f40.idx" 2049 0) = 0 3 "/media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37" (null)
62->dir_lookup ("media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37c" 2049 0) = 0 1 "/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5" 61
61->dir_lookup ("home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5d" 2049 0) = 0 1 "" 84
task3741-> 3206 (pn{ 33}) = 0
84->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID)
84->io_stat_request () = 0 {1 704 0 36308992 0 0 -1 33060 1 1000 1000 4712 0 1307711395 0 1307657003 0 1307657003 0 4096 16 0 1000 0 0 100663296 1836017780 29537 0 0 0 0}
84->io_map_request () = 0x4000002d (Operation not supported)
84->io_map_request () = 0x4000002d (Operation not supported)
76->io_write_request ("fatal: Out of memory? mmap failed: No such device
" -1) = 0 50
64->proc_mark_exit_request (32768 0) = 0
task3741-> 2008 () = 0
Child 3741 exited with 128
This is the libnetfs: io map issue.
There is a NO_MMAP conditional in Git's source code, but it is a compile-time
conditional. The fallback code in compat/mmap.c:git_mmap only supports
MAP_PRIVATE, and simply preads in the requested portion of a file. This
could be made a runtime fallback, too.
Open Issues
dhclient aborting with a stack smashing error
IRC, freenode, #hurd, 2013-08-21:
<teythoon> yay, I fixed the path of the dhcp leases file... <teythoon> ... and now dhclient dies of a buffer overflow <teythoon> fortunately the fix is rather simple, anyone who cares about the security of his box just has to stop using isc software <teythoon> the code is full of stuff like char foo[100]; /* surely that's enough */ <pinotree> note that our version of isc-dchp (the one in ports) is older than the latest one available in unstable (which is still older than the latest upstream releases) <teythoon> so? <pinotree> dunno, might have been fixed or not <teythoon> ^^ yeah sure <gnu_srs> A lot of software has these limitations and PATH_MAX, MAXPATHLEN issues :( <pinotree> having a limitation is not a problem per-se <teythoon> no, only software written in c has these kind of problems <pinotree> the problem is not checking whether the limits are hit <teythoon> well, looking at the source of isc-dhcp my time is better spent making another dhcp client work on hurd <teythoon> also reading up on bug #616290 does make me want to avoid touching it ever <braunr> hehe <gnu_srs> teythoon: somebody was offering an alternative to the isc dhcpclient, but I think it was rejected by Samuel? <teythoon> why would he do that? <braunr> probably for compliance <gnu_srs> He probably thought they would release a new version soon, is 4.3.0 out yet? <teythoon> well, as soon as my fixes for ifupdown go in, dhclient will start crashing <teythoon> no, there is no new version released <teythoon> no major one that is <teythoon> 4.2.5 is out <gnu_srs> can't you just increase the buffer size, where is the problem exactly? <teythoon> I have no idea <gnu_srs> The Hurd patches are not in 4.2.5, they were promised for 4.3.0a1. <gnu_srs> Still the buffer overflow problem might be present in 4.2.5 if patched to build on Hurd. <braunr> there, darnassus now has a fully featured git/gitweb service <teythoon> :) <teythoon> btw, I managed to reproduce the crash reliably <teythoon> rm /var/lib/dhcp/*; dhclient -v /dev/eth0 ... *boom* <teythoon> ditch the -v, everything works, and now that there is a lease file, you can add the -v again and it works <braunr> ew :) <teythoon> and what has dhclient.c to say for its defense? <teythoon> log_info("%s", ""); <teythoon> hm, not much :/IRC, freenode, #hurd, 2013-08-22:
<teythoon> uh, the isc-dhcp situation is a huge pita, the source on -ports does not compile anymore :/IRC, freenode, #hurd, 2013-08-23:
<gnu_srs> teythoon: Was it the slash in the network interface names that caused the buffer overflow in dhclient? <teythoon> gnu_srs: no, previously no dhcp leases file was written and everything was fine <pinotree> teythoon: did you really develop your patch against that old version of ifupdown? <teythoon> gnu_srs: now it is written, and for some reason dhclient crashes *iff* -v is given *and* there is no previous lease file <teythoon> pinotree: no, I did not. that was only reportbug including information from my desktop machine without asking me <teythoon> but when I first looked at ifupdown it was still a 6000 lines noweb file >,< <teythoon> that was fun <pinotree> which version is it against? <teythoon> hg tipIRC, freenode, #hurd, 2013-08-30:
<tschwinge> teythoon: I understand correctly that you found that id:"874ngfvwn4.fsf@kepler.schwinge.homeip.net" in fact was really "just" a buffer overflow in the dhclient code? <teythoon> tschwinge: ah, most interesting, I didn't realize that you stumbled across this as well <teythoon> to be honest I don't know what's going on there, I only observed what I wrote in my report <teythoon> for me it started crashing once the lease file was actually a valid path (i.e. not to a non-existing directory b/c of the slashes in /dev/eth0) <teythoon> I tried to rebuild the package served on debian-ports, but that failedIRC, freenode, #hurd, 2014-01-03:
<congzhang> dhcp 4.3 alpha released <congzhang> and PATH_MAX issue was fixedIRC, freenode, #hurd, 2014-01-21:
<gnu_srs> teythoon: what about this? *** stack smashing detected ***: dhclient terminated <teythoon> gnu_srs: well, dhclient dies <teythoon> i've seen this, it comes and goes <teythoon> not sure what happens, but i tend to blame it on our custom-built dhcp package <teythoon> from debian-ports, and it's outdated <teythoon> it's most likely not your fault <gnu_srs> i thought there was a new upstream by now <teythoon> and the network configuration can be done with passive translators as it was always done <teythoon> there was ? <gnu_srs> there is one recently released, haven't checked yet <gnu_srs> in experimental: 4.3.0a1-2, does still not build out of the box <teythoon> there was, but it does not seem to build on the hurd <teythoon> https://buildd.debian.org/status/logs.php?pkg=isc-dhcp&arch=hurd-i386 <teythoon> the most recent version is from debian-portsIRC, freenode, #hurd, 2014-01-24:
<braunr> stack smashing detected ***: dhclient terminated <braunr> how nice <tschwinge> braunr: dhclient: http://news.gmane.org/find-root.php?message_id=%3C874ngfvwn4.fsf%40kepler.schwinge.homeip.net%3E <tschwinge> braunr: And I thought, teythoon had found this to be a buffer overflow; something like char dev[10], and for us the path to the dev (/dev/eth0) was longer (but I may be misremebering). <braunr> tschwinge: sounds reasonable <tschwinge> braunr: By the way: I'm seeing this segfault all the time during boot, but when I again run it manually (root login), it works fine. <braunr> tschwinge: you mean the dhclient one µ? <tschwinge> Yes. <braunr> mhm <teythoon> braunr, tschwinge: i never found the cause of the dhclient issue <teythoon> i blame the (outdated) build on debian-portsIRC, freenode, #hurd, 2014-01-30:
<youpi> err, still nobody found the dhclient bug? <gnu_srs> youpi: You found the dh-client bug, right? <youpi> gnu_srs: yes, the dhclient bug was in libc, as tschwinge guessed <youpi> I'll probably upload a fixed glibc on debian-ports <gnu_srs> youpi: dhclient starts OK with libc 2.17-98~0 <youpi> btw, the experimental version of isc-dhcp has a newer occurrence of PATH_MAX <gnu_srs> :-( <youpi> (aside from not including the needed debian files for hurd-i386)IPv6
IRC, freenode, #hurd, 2014-02-23:
<gg0> seems dhclient can't also set ipv6 translator <gg0> cheated by setting it manually, i had probably screwed it up somehow <gg0> exim was complaining 2014-02-23 22:26:41 IPv6 socket creation failed: Address family not supported by protocol
Comparing to GNU/Linux, on GNU/Hurd it happens much more often and easily for screen sessions to become dead. This is annoying, as it defeats one of screen's main purposes.
One reproducible scenario goes like this
ssh [somewhere],start a screen session, and some long-running process P in there,
at some point the link is forcefully terminated (also known as disconnect after 24 hours with consumer DSL),
P will continue to execute,
at some point, P will terminate / hang (after having received some kind of signal?), and the screen session will be reported as dead.
Another one, not as often reproduced
ssh [somewhere],start a screen session, and some long-running process P in there,
at some point the link is forcefully terminated (also known as disconnect after 24 hours with consumer DSL),
ssh [somewhere],screen -x, and notice that P will immediatelly terminate / hang (after having received some kind of signal?), and the screen session will immediatelly be reported as dead. (Perhaps the other way round: upon re-attaching, the screen session goes bonkers and takes P with it?)
IRC, freenode, #hurd, 2011-10-19
<antrik> tschwinge: hm... haven't seen screen dying in a long time
<tschwinge> antrik: It's easy, and goes like this: have a session on one
system, log in from another, do screen -x and wait some time.
<antrik> I do this regularily. haven't had a crash in ages.
<antrik> (BTW, I'm not sure I ever had a crash on srceen -x... at that
time, I wasn't using -x. I often had crashes with screen -r. my
impression back then was that it works better when doing -rd -- in fact,
I always do that now, so I can't say whether crashes still happen with
only -r...)
2011-10-26:
<antrik> so I was saying the other day that I haven't had a screen crash in
a long time... well, here it was :-(
<antrik> this time it didn't crash on reconnect though, but already
before. probably when I killed the hanging ssh connection
On 2010-11-28, Austin English contacted us, stating that he's working on porting Wine to the GNU/Hurd.
It is not yet clear how difficult this is going to be, what sort of requirements Wine has: only libc / POSIX / etc., or if there are advanced things like system call trapping involved, too.
Samuel suspects that there's some need for LDT table allocation. There is kernel support for this, however.
IRC, freenode, #hurd, 2011-08-11
< arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM,
and to that end, I've successfully compiled the latest sources from Git
after installing the libc (devel) packages from experimental and
personally patching Wine with http://pastebin.com/rg6dx09G
< arethusa> my question is, when trying to launch Wine, I'm seeing "wine
client error:0: sendmsg: (os/kern) invalid address" from the client side,
whereas the wineserver seems to be starting and running correctly, how
could I debug this issue further? using rpctrace doesn't seem to help, as
the trace just hangs when run on the Wine loader instead of yielding
insight
< kilobug> arethusa: isn't there a wine debuguer that can start a gdb when
wine encounters an error or something like that ?
< arethusa> it's too early for that
< kilobug> or least give you a full traceback of the wine code where the
error occur ?
< arethusa> the error is happening during initial connect to the
wineserver, in dlls/ntdll/server.c
< arethusa> but that doesn't help me figure out why sendmsg would error out
in this way
< arethusa>
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361
< azeem_> arethusa: probably some of the msghdr entries are not supported
by the Hurd's glib
< azeem_> c
< pinotree> haha, socket credentials, which we don't support yet
< azeem_> yep
< pinotree> youpi: ↑ another case ;)
< azeem_> arethusa: just implement those and it should work
< kilobug> in pflocal ? or glibc ?
< pinotree> pflocal
< arethusa> azeem_: hmm, okay, thanks
< pinotree> arethusa: their lack is a known issue, and makes things like
dbus and gamin not work
< arethusa> it's
https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and
related links I assume?
< youpi> yes
< pinotree> (but that patch is lame)
IRC, freenode, #hurd, 2013-10-02
<gnu_srs> youpi: I've come a little further with wine, see debian bug
#724681 (same problem).
<gnu_srs> Now the problem is probably due to the specific address space
and stack issues to be
<gnu_srs> fixed for wine to run as braunr pointed out some months ago
(IRC?) when we discussed wine.
IRC, freenode, #hurd, 2013-12-29
<Andre_H> Hi,
http://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html seems
fixed in Debian GNU/Hurd 2013, do you know which patch they used? i
already asked in their channel, but well, there are only 18 people :)
<youpi> Andre_H: it hasn't been fixed in Debian GNU/Hurd. Work is discussed
on the bug-hurd mailing list
<Andre_H> youpi: thx for the info, i wonder why wine now works with some
hacks, but didn't in the past
<youpi> I guess some circumvention patch was added to wine
<youpi> does it actually really work, as in running applications for real?
<youpi> (I've nevere tried)
<Andre_H> youpi: i'm a wine developer and haven't seen circumventions for
hurd... i also just tried winelib apps last night, will try... let's say
powerpoint viewer today
<gnu_srs> Andre_H: How did you make wine run? I have patches for wine-1.4.1
and 1.6.1 to build (so far unpublished), but it does not yet run
properly.
<gnu_srs> test case: wine notepad
<Andre_H> gnu_srs: what's happening when you try that?
<gnu_srs> Andre_H: Currently it hangs at connect() (after creating the
/tmp/.wine1000/.../socket, etc, and starting again)
<gnu_srs> seems to be some problem with the HURD_DPORT_USE macro in eglibc,
investigation ongoing
<Andre_H> gnu_srs: well, i'm using the debian distro, maybe you're on
something else? you could also pastebin your hacks, so i could have a
look. i'm about to clean mine up to send them upstream... ntdll will be
quite hard...
IRC, freenode, #hurd, 2013-12-30
<gnu_srs> wine runs:)
<gnu_srs> It's just extremely slow.,..
<gnu_srs> gg0: please don't reopen #733604 , I've filed an updated one:
#7336045
<gnu_srs> #733605
<gg0> gnu_srs: i've reassigned it from wine-1.6 (nonexistent) to wine
(correct), then to src:wine (more correct), but between such
reassignments you closed it so found command in the latter made it
reopening
<gg0> then i realized you could mess up bugs on your own, without help :)
<gnu_srs> gg0: tks anyway, now it is src:wine and the title is right. Maybe
you should have noted me on IRC?
<Andre_H> gnu_srs: what's your status about wine? i'm still about to get
things upstream...
<gnu_srs> Andre_H: see debian bug #733605
IRC, freenode, #hurd, 2013-12-31
<Andre_H> gnu_srs: i didn't need the patches for
dlls/mountmgr.sys/diskarb.c, maybe due to missing headers
IRC, freenode, #hurd, 2014-01-06
<Andre_H> Wanted to note that
http://www.gnu.org/software/hurd/open_issues/wine.html is wrong about
socket credentials, afaik they are still not implemented but that doesn't
block Wine anymore
<Andre_H> In fact all you need to run Wine are the patches followed by
https://source.winehq.org/patches/data/101439 (not yet upstream) or see
http://wiki.winehq.org/Hurd
<braunr> Andre_H: thanks for your report
<Andre_H> np :)
<Andre_H> braunr: can someone update
http://www.gnu.org/software/hurd/open_issues/wine.html please?
<braunr> Andre_H: well, you can :)
<Andre_H> log in with google -> check guidelines of your wiki -> try out
your wiki syntax -> laziness alarm :)
<gnu_srs> Andre_H: The reason why wine runs now is a bug in SCM_CREDS was
fixed, see the wine-devel ML.
<gnu_srs> Andre_H: s/SCM_CREDS/SCM_RIGHTS/
<Andre_H> gnu_srs: already updated our wiki :)
<Andre_H> gnu_srs: would you mind updating yours:
http://www.gnu.org/software/hurd/open_issues/wine.html :)
<Andre_H> gnu_srs: two commits for wine are in now :)
IRC, freenode, #hurd, 2014-01-11
<gnu_srs1> Andre_H: Looks like the two committed patches did not go into
wine-1.6.2:-(
<gnu_srs1> Additionally, your PATH_MAX fixes was not accepted?
<Andre_H> gnu_srs1: well, the stable branch is called stable because not
everything get's there :)7
<Andre_H> gnu_srs1: the PATH_MAX patch needs more thinking...
IRC, freenode, #hurd, 2015-02-09
<Andre_H> since Wine 1.7.28 it runs quite well on Gnu/Hurd - wiki.winehq.org/Hurd
<Andre_H> ( https://source.winehq.org/git/wine.git/commitdiff/6d50cfcac28f84e07777fc10874887356832102e )
Here's what's to be done for maintaining Boehm GC.
This one does need Hurd-specific configuration.
It is, for example, used by GCC (which has its own fork), so any changes committed upstream should very like also be made there.
General information
Configuration
Last reviewed up to Git commit d6c34577eeaba37ff08998d18676531082c040b6
(2016-03-18), and for libatomic_ops to Git commit
01d2509c13f3aa7e03cb4cbf50fda08f98725ce4 (2016-03-24).
configure.acPARALLEL_MARKis not enabled; doesn't make sense so far.*-*-kfreebsd*-gnudefinesUSE_COMPILER_TLS. What's this, and why does not other config?TODO
[ if test "$enable_gc_debug" = "yes"; then AC_MSG_WARN("Should define GC_DEBUG and use debug alloc. in clients.") AC_DEFINE([KEEP_BACK_PTRS], 1, [Define to save back-pointers in debugging headers.]) keep_back_ptrs=true AC_DEFINE([DBG_HDRS_ALL], 1, [Define to force debug headers on all objects.]) case $host in x86-*-linux* | i586-*-linux* | i686-*-linux* | x86_64-*-linux* ) AC_DEFINE(MAKE_BACK_GRAPH) AC_MSG_WARN("Client must not use -fomit-frame-pointer.") AC_DEFINE(SAVE_CALL_COUNT, 8) ;; AM_CONDITIONAL([KEEP_BACK_PTRS], [test x"$keep_back_ptrs" = xtrue])
configure.hostNothing.
Makefile.am,include/include.am,cord/cord.am,doc/doc.am,tests/tests.amNothing.
include/gc_config_macros.hShould be OK.
include/private/gcconfig.hHairy. But should be OK. Search for HURD, compare to LINUX, I386 case.
See
doc/porting.htmlanddoc/README.macros(and others) for documentation.LINUX has:
#define LINUX_STACKBOTTOMDefined instead of
STACKBOTTOMto have the value read from/proc/.#define HEAP_START (ptr_t)0x1000May want to define it for us, too?
#ifdef USE_I686_PREFETCH,USE_3DNOW_PREFETCH--- [...]Apparently these are optimization that we also could use. Have a look at LINUX for X86_64, which uses
__builtin_prefetch(which Linux x86 could use, too?).TODO
#if defined(LINUX) && defined(USE_MMAP) /* The kernel may do a somewhat better job merging mappings etc. */ /* with anonymous mappings. */ # define USE_MMAP_ANON #endif[Hurd] Use mmap instead of sbrk, https://github.com/ivmai/bdwgc/pull/95.
TODO
#if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) /* Nptl allocates thread stacks with mmap, which is fine. But it */ /* keeps a cache of thread stacks. Thread stacks contain the */ /* thread control blocks. These in turn contain a pointer to */ /* (sizeof (void *) from the beginning of) the dtv for thread-local */ /* storage, which is calloc allocated. If we don't scan the cached */ /* thread stacks, we appear to lose the dtv. This tends to */ /* result in something that looks like a bogus dtv count, which */ /* tends to result in a memset call on a block that is way too */ /* large. Sometimes we're lucky and the process just dies ... */ /* There seems to be a similar issue with some other memory */ /* allocated by the dynamic loader. */ /* This should be avoidable by either: */ /* - Defining USE_PROC_FOR_LIBRARIES here. */ /* That performs very poorly, precisely because we end up */ /* scanning cached stacks. */ /* - Have calloc look at its callers. */ /* In spite of the fact that it is gross and disgusting. */ /* In fact neither seems to suffice, probably in part because */ /* even with USE_PROC_FOR_LIBRARIES, we don't scan parts of stack */ /* segments that appear to be out of bounds. Thus we actually */ /* do both, which seems to yield the best results. */ # define USE_PROC_FOR_LIBRARIES #endifTODO
# if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) \ && !defined(INCLUDE_LINUX_THREAD_DESCR) /* Will not work, since libc and the dynamic loader use thread */ /* locals, sometimes as the only reference. */ # define INCLUDE_LINUX_THREAD_DESCR # endifTODO
# if defined(UNIX_LIKE) && defined(THREADS) && !defined(NO_CANCEL_SAFE) \ && !defined(PLATFORM_ANDROID) /* Make the code cancellation-safe. This basically means that we */ /* ensure that cancellation requests are ignored while we are in */ /* the collector. This applies only to Posix deferred cancellation;*/ /* we don't handle Posix asynchronous cancellation. */ /* Note that this only works if pthread_setcancelstate is */ /* async-signal-safe, at least in the absence of asynchronous */ /* cancellation. This appears to be true for the glibc version, */ /* though it is not documented. Without that assumption, there */ /* seems to be no way to safely wait in a signal handler, which */ /* we need to do for thread suspension. */ /* Also note that little other code appears to be cancellation-safe.*/ /* Hence it may make sense to turn this off for performance. */ # define CANCEL_SAFE # endifCAN_SAVE_CALL_ARGSvs. -fomit-frame-pointer now being on by default for Linux x86 IIRC? (Which is an open issue gcc for not including us.)TODO
# if defined(REDIRECT_MALLOC) && defined(THREADS) && !defined(LINUX) # error "REDIRECT_MALLOC with THREADS works at most on Linux." # endifTODO
#if ((defined(UNIX_LIKE) && (defined(DARWIN) || defined(HURD) \ || defined(OPENBSD) || defined(ARM32) \ || defined(MIPS) || defined(AVR32) \ || defined(OR1K) || defined(NIOS2))) \ || (defined(LINUX) && !defined(__gnu_linux__)) \ || (defined(RTEMS) && defined(I386)) || defined(PLATFORM_ANDROID)) \ && !defined(NO_GETCONTEXT) # define NO_GETCONTEXT #endifAlso see comment below, regarding
mach_dep.c.
HURD has:
#define STACK_GROWS_DOWN#define HEURISTIC2Defined instead of
STACKBOTTOMto have the value probed.Linux also has this:
#if defined(LINUX_STACKBOTTOM) && defined(NO_PROC_STAT) \ && !defined(USE_LIBC_PRIVATES) /* This combination will fail, since we have no way to get */ /* the stack base. Use HEURISTIC2 instead. */ # undef LINUX_STACKBOTTOM # define HEURISTIC2 /* This may still fail on some architectures like IA64. */ /* We tried ... */ #endifBeing on glibc, we could perhaps do similar as
USE_LIBC_PRIVATESinstead ofHEURISTIC2. Pro: avoidSIGSEGV(and general fragility) during probing at startup (if I'm understanding this correctly). Con: rely on glibc internals. Or we instead add support to parse/proc/(can even use the same as Linux?), or use some other interface.
This is also likely the issue causing the GDBGC_find_limit_with_boundSIGSEGV startup confusion described in binutils.#define SIG_SUSPEND SIGUSR1,#define SIG_THR_RESTART SIGUSR2We don't
#define MPROTECT_VDB(WIP comment); but Linux neither.Where does our
GETPAGESIZEcome from? Should we#include <unistd.h>like it is done for LINUX?[Hurd] Use mmap instead of sbrk, https://github.com/ivmai/bdwgc/pull/95.
include/gc_pthread_redirects.hTODO
Cancellation stuff is Linux-only. In other places, too.
mach_dep.c#define NO_GETCONTEXTopen issue glibc, but this is not a real problem here, because we can use the following GCC internal function without much overhead: [TODO]
Also see comment above, regarding
include/private/gcconfig.h.GC_with_callee_saves_pushedThe
HAVE_BUILTIN_UNWIND_INITcase is ours.
os_dep.c- TODO.
dyn_load.cFor
DYNAMIC_LOADING. TODO.pthread_support.c,pthread_stop_world.cTODO.
TODO.
Other files also contain LINUX and other conditionals.
libatomic_ops/configure.acNothing.
Makefile,src/Makefile,src/atomic_ops/Makefile,src/atomic_ops/sysdeps/Makefile,doc/Makefile,tests/MakefileNothing.
src/atomic_ops/sysdeps/gcc/x86.hNothing.
b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all correct.
mmap, b64dd3bc1e5a23e677c96b478d55648a0730ab75This is (still) stale/redundant/unused, as far as I can tell.
parallel mark, 07c2b8e455c9e70d1f173475bbf1196320812154, pass--disable-parallel-markor enable for us, too?HANDLE_FORK, e9b11b6655c45ad3ab3326707aa31567a767134b, 806d656802a1e3c2b55cd9e4530c6420340886c9, 1e882b98c2cf9479a9cd08a67439dab7f9622924Check
include/private/thread_local_alloc.hreUSE_COMPILER_TLS/USE_PTHREAD_SPECIFIC.TODO:
diff --git ./include/private/gcconfig.h ./include/private/gcconfig.h{+#if defined(LINUX) || defined(FREEBSD) || defined(SOLARIS) || defined(IRIX5) \+} {+ || ((defined(USE_MMAP) || defined(USE_MUNMAP)) && !defined(USE_WINALLOC))+} {+# define MMAP_SUPPORTED+} {+#endif+}diff --git ./include/private/gcconfig.h ./include/private/gcconfig.h#if !defined(CAN_HANDLE_FORK) && !defined(NO_HANDLE_FORK) \ && [-((defined(GC_PTHREADS)-]{+!defined(HAVE_NO_FORK) \+} && [-!defined(HURD)-]{+((defined(GC_PTHREADS)+} && !defined(NACL) \ &&[-!defined(PLATFORM_ANDROID) &&-] !defined(GC_WIN32_PTHREADS)[-\-] && !defined(USE_WINALLOC)) \ || (defined(DARWIN) && defined(MPROTECT_VDB)) || defined(HANDLE_FORK)) /* Attempts (where supported and requested) to make GC_malloc work in */ /* a child process fork'ed from a multi-threaded parent. */ # define CAN_HANDLE_FORK #endif {+#if defined(CAN_HANDLE_FORK) && !defined(CAN_CALL_ATFORK) \+} {+ && !defined(HURD) && !defined(PLATFORM_ANDROID)+} {+ /* Have working pthread_atfork(). */+} {+# define CAN_CALL_ATFORK+} {+#endif+}diff --git ./include/private/gcconfig.h ./include/private/gcconfig.h{+#if (defined(FREEBSD) || (defined(DARWIN) && !defined(_POSIX_C_SOURCE)) \+} {+ || (defined(SOLARIS) && (!defined(_XOPEN_SOURCE) \+} {+ || defined(__EXTENSIONS__))) \+} {+ || defined(LINUX)) && !defined(HAVE_DLADDR)+} {+# define HAVE_DLADDR+} {+#endif+}diff --git ./os_dep.c ./os_dep.c@@ -3038,9 +3005,11 @@ GC_API GC_push_other_roots_proc GC_CALL GC_get_push_other_roots(void) /* Also old MSWIN32 ACCESS_VIOLATION filter */ # if !defined(MSWIN32) && !defined(MSWINCE) STATIC SIG_HNDLR_PTR GC_old_bus_handler = 0; {+# if defined(FREEBSD) || defined(HURD) || defined(HPUX)+} STATIC GC_bool GC_old_bus_handler_used_si = FALSE; {+# endif+} STATIC GC_bool GC_old_segv_handler_used_si = FALSE;diff --git ./os_dep.c ./os_dep.c@@ -3192,20 +3169,22 @@ GC_API GC_push_other_roots_proc GC_CALL GC_get_push_other_roots(void) # else GC_bool used_si; {+# if defined(FREEBSD) || defined(HURD) || defined(HPUX)+} if (sig == [-SIGSEGV) {-] [- old_handler = GC_old_segv_handler;-] [- used_si = GC_old_segv_handler_used_si;-] [- } else-]{+SIGBUS)+} { old_handler = GC_old_bus_handler; used_si = GC_old_bus_handler_used_si; {+} else+} {+# endif+} {+ /* else */ {+} {+ old_handler = GC_old_segv_handler;+} {+ used_si = GC_old_segv_handler_used_si;+} } # endifdiff --git ./os_dep.c ./os_dep.c# if defined(HPUX) || defined(LINUX) || defined(HURD) \ || (defined(FREEBSD) && defined(SUNOS5SIGS)) sigaction(SIGBUS, &act, &oldact); if [-(oldact.sa_flags-]{+((oldact.sa_flags+} & SA_SIGINFO) {+!= 0)+} { GC_old_bus_handler = oldact.sa_sigaction; {+# if !defined(LINUX)+} GC_old_bus_handler_used_si = TRUE; {+# endif+} } else { GC_old_bus_handler = (SIG_HNDLR_PTR)oldact.sa_handler; {+# if !defined(LINUX)+} GC_old_bus_handler_used_si = FALSE; {+# endif+} } if (GC_old_bus_handler == (SIG_HNDLR_PTR)SIG_IGN) { [-if (GC_print_stats)-] [- GC_err_printf("Previously-]{+WARN("Previously+} ignored bus [-error!?\n");-]{+error!?\n", 0);+} {+# if !defined(LINUX)+} GC_old_bus_handler = (SIG_HNDLR_PTR)SIG_DFL; {+# else+} {+ /* GC_old_bus_handler is not used by GC_write_fault_handler. */+} {+# endif+} } {+else+} if (GC_old_bus_handler != (SIG_HNDLR_PTR)SIG_DFL) { [-if (GC_print_stats == VERBOSE)-] [- GC_log_printf("Replaced-]{+GC_VERBOSE_LOG_PRINTF("Replaced+} other SIGBUS handler\n"); } # endif /* HPUX || LINUX || HURD || (FREEBSD && SUNOS5SIGS) */
Build
Here's a log of a boehm-gc build run; this is from Git commit
d6c34577eeaba37ff08998d18676531082c040b6 (2016-03-18), and for libatomic_ops
Git commit 01d2509c13f3aa7e03cb4cbf50fda08f98725ce4 (2016-03-24), run on
kepler.SCHWINGE and laplace.SCHWINGE.
$ export LC_ALL=C
$ (cd ../master/ && ln -sfn ../libatomic_ops/master libatomic_ops)
$ (cd ../master/ && autoreconf -vfi)
$ ../master/configure --prefix="$PWD".install SHELL=/bin/bash CC=gcc-4.9 CXX=g++-4.9 --enable-cplusplus --enable-gc-debug --enable-gc-assertions --enable-assertions 2>&1 | tee log_build
[...]
$ make 2>&1 | tee log_build_
[...]
Different hosts may default to different shells and compiler versions; thus harmonized. Using bash instead of dash as otherwise libtool explodes.
Analysis
$ toolchain/logs/process boehm-gc build
only GNU/Linux:
configure: WARNING: "Explicit GC_INIT() calls may be required."only GNU/Linux:
configure: WARNING: "Client must not use -fomit-frame-pointer."
Install
$ make install 2>&1 | tee log_install
[...]
Analysis
$ toolchain/logs/process boehm-gc install
Testsuite
$ make -k check 2>&1 | tee log_test
[...]
$ (cd libatomic_ops/ && make -k check) 2>&1 | tee log_test_
[...]
Analysis
$ toolchain/logs/process boehm-gc test
There are different configurations possible, but in general, the testsuite restults of GNU/Linux and GNU/Hurd look very similar.
GNU/Hurd is missing
Call chain at allocation: [...]output.os_dep.c:GC_print_callers
TODO
What are other applications to test Boehm GC? Also especially in combination with libpthread and dynamic loading of shared libraries?
There are patches (apparently not committed) that GCC itself can use it, too: http://gcc.gnu.org/wiki/Garbage_collection_tuning.
There's been some talking about it on GNU guile mailing lists, and two Git branches (2010-12-15: last change 2009-09).
IRC, OFTC, #debian-hurd, 2012-02-05
<pinotree> youpi: i think i found out the possible cause of the ecl and
mono issuess
<pinotree> -s
<youpi> oh
<pinotree> basically, we don't have the realtime signals (so no
SIGRTMIN/SIGRTMAX defined), hence things use either SIGUSR1 or
SIGUSR2... which are used in libgc to resp. stop/resume threads when
"collecting"
<pinotree> i just patched ecl to use SIGINFO instead of SIGUSR1 (used when
no SIGRTMIN+2 is available), and it seems going on for a while
<youpi> uh, why would SIGINFO work better than SIGUSR1?
<pinotree> it was a test, i tried the first "not common" signal i saw
<pinotree> my test was, use any signal different than USR1/2
<youpi> ah, sorry, I hadn't understood
<youpi> you mean there's a conflict between ecl and mono using SIGUSR1, as
well as libgc?
<pinotree> yes
<pinotree> for example, in ecl sources see src/c/unixint.d,
install_process_interrupt_handler()
<youpi> SIGINFO seems a sane choice
<youpi> SIGPWR could have been a better choice if it was available :)
<pinotree> i would have chose an "unassigned" number, say SIGLOST (the
bigger one) + 10, but it would be greater than _NSIG (and thus discarded)
<youpi> not a good idea indeed
<pinotree> it seems that linux, beside the range for rt signals, has some
"free space"
<pinotree> i'll start now another ecl build, from scratch this time, with
s/SIGUSR1/SIGINFO/ (making sure ctags won't bother), and if it works i'll
update svante's bug
<pinotree> mmap(...PROT_NONE...) failed
<pinotree> hmm...
<pinotree> apparently enabling MMAP_ANON in mono's libgc copy was a good
step, let's see
IRC, OFTC, #debian-hurd, 2012-03-18
<pinotree> youpi: mono is afflicted by the SIGUSR1/2 conflict with libgc
<youpi> pinotree: didn't we have a solution for that?
<pinotree> well, it works just for one signal
<pinotree> the ideal solution would be having a range for RT signals, and
make libgc use RTMIN+5/6, like done on most of other OSes
<youpi> but we don't have RT signals, do we?
<pinotree> right :(
IRC, freenode, #hurd, 2012-03-21
<pinotree> civodul: given we have to realtime signals (so no range of
signals for them), libgc uses SIGUSR1/2 instead of using SIGRTMIN+5/6 for
its thread synchronization stuff
<pinotree> civodul: which means that if an application using libgc then
sets its own handlers for either of SIGUSR1/2, hell breaks
<civodul> pinotree: ok
<civodul> pinotree: is it a Debian-specific change, or included upstream?
<pinotree> libgc using SIGUSR1/2? upstream
<civodul> ok
IRC, freenode, #hurd, 2013-09-03
<congzhang> braunr: when will libc malloc say memory corruption?
<braunr> congzhang: usually on free
<braunr> sometimes on alloc
<congzhang> and after one thread be created
<congzhang> I want to know why and how to find the source
<congzhang> does libgc work well on hurd?
<braunr> i don't think it does
<congzhang> so , why it can't?
<braunr> congzhang: what ?
<congzhang> libgc was not work on hurd
<pinotree> why?
<congzhang> I try porting dotgnu
<braunr> ah
<braunr> nested signal handling
<congzhang> one program always receive Abort signal
<pinotree> and why it should be a problem in libgc?
<congzhang> for malloc memory corruption
<braunr> libgc relies on this
<congzhang> yes
<congzhang> so, is there a workaround to make it work?
<braunr> show the error please
<congzhang> http://paste.debian.net/34416/
<pinotree> where's libgc?
<congzhang> i compile dotgnu with enable-gc
<pinotree> so?
<congzhang> I am not sure about it
<pinotree> so why did you say earlier that libgc doesn't work?
<congzhang> because after I see one thread was created notice by gdb, it
memory corruption
<pinotree> so what?
<congzhang> maybe gabage collection happen, and gc thread start
<pinotree> that's speculation
<pinotree> you cannot debug things speculating on code you don't know
<pinotree> less speculation and more in-deep debugging, please
* congzhang I try again, to check weather thread list changing
<congzhang> sorry for this
<braunr> it simply looks like a real memory corruption (an overflow)
<congzhang> maybe PATH related problem
<pinotree> PATH?
<congzhang> yes
<braunr> PATH_MAX
<braunr> but unlikely
<congzhang> csant do path traverse
<congzhang> I fond the macro
<congzhang> found
<congzhang> #if defined(__sun__) || defined(__BEOS__)
<congzhang> #define BROKEN_DIRENT 1
<congzhang> #endif
<congzhang> and so for hurd?
<pinotree> BROKEN_DIRENT doesn't say much about what it does
<WhiteKIBA> nope
<WhiteKIBA> whoops
<congzhang> it seems other port meet the trouble too
<pinotree> which trouble?
<congzhang> http://comments.gmane.org/gmane.comp.gnu.dotgnu.developer/3642
<congzhang> (gdb) ptype struct dirent
<congzhang> type = struct dirent {
<congzhang> __ino_t d_ino;
<congzhang> unsigned short d_reclen;
<congzhang> unsigned char d_type;
<congzhang> unsigned char d_namlen;
<congzhang> char d_name[1];
<congzhang> }
<congzhang>
<congzhang> d_name should be char[PATH_MAX]?
<congzhang> and
http://libjit-linear-scan-register-allocator.googlecode.com/svn/trunk/pnet/support/dir.c
<pinotree> no
<braunr> stop pasting that much
<_d3f> uhm PATH_MAX on the hurd?
<braunr> and stop saying nonsense
<congzhang> sorry, i think four line was not worth to pastbin
<pinotree> they are 8
<congzhang> never again
<braunr> just try by defining BROKEN_DIRENT to 1 in all cases and see how
it goes
* congzhang read dir.c again
<congzhang> braunr: it does not crash this time, I do more test
IRC, freenode, #hurd, 2013-09-04
<congzhang> hi, I am dotgnu work on hurd, and even winforms app
<congzhang> s/am/make
<congzhang> and maybe c# hello world translate another day :)
IRC, freenode, #hurd, 2013-12-16
<braunr> gnu_srs: ah, libgc
<braunr> there are signal-related problems with libgc
Leak Detection
IRC, freenode, #hurd, 2013-10-17
<teythoon> I spent the last two days integrating libgc - the boehm
conservative garbage collector - into hurd
<teythoon> it can be used in leak detection mode
<azeem> whoa, cool
<teythoon> and it actually kind of works, finds malloc leaks in translators
<braunr> i think there were problems with signal handling in libgc
<braunr> i'm not sure we support nested signal handling well
<teythoon> yes, I read about them
<teythoon> libgc uses SIGUSR1/2, so any program installing handlers on them
will break
<azeem> (which is not a problem on Linux, cause there some RT-signals or so
are used)
<teythoon> yes
There is a FOSS Factory bounty (p274) on this task.
There are now specialized variants of Debian's libc package, libc0.3-i686 and libc0.3-xen.
On Thu, Oct 07, 2010 at 11:22:46AM +0200, Samuel Thibault wrote:
Thomas Schwinge, le Thu 07 Oct 2010 10:11:07 +0200, a écrit :
Also, this text says ``will be selected instead when running under Xen'' -- is this meant to be automatically done?
It's supposed to be, we need to add support for it.
If so, then it didn't work.
Yes, you need to copy it by hand. Same for libc0.3-i686, we just need to steal the cpuid code from the kfreebsd port of glibc.
IRC, freenode, #hurd, 2013-06-30
<pinotree> other than that, the hwcap system is not working for us yet,
right?
<youpi> no but we'd like to use e.g. cpuid for that
<youpi> like kfreebsd does
<pinotree> do they use cpuid for that?
<pinotree> i kind of lost myself in glibc's loading internals, trying to
find out where the hwcap bits come from
<youpi> on linux it comes from the kernel
<youpi> on kfreebsd aiui they use cpuid to figure it out from the process
itself
<pinotree> do you have any pointer to the kfreebsd way? iirc i had a look
in their sysdeps, but found nothing related to that
<youpi> it's in local-sysdeps.diff aiui
<youpi> +dl_platform_kfreebsd_i386_init
<youpi> which fills dl_hwcap
<youpi> called at _dl_sysdep_start
<pinotree> interesting
Having working CPUID code inside glibc is also a prerequisite for proper IFUNC support.
Will need to have something like Linux' cgroups. Introduction: Ressourcen-Verwaltung mit Control Groups (cgroups) (german), Daniel Gollub, Stefan Seyfried, 2010-10-14.
Likely there's also some other porting needed.
Discussion
This also captures discussion about other init systems, not only systemd. Also note the additional upstart page.
IRC, OFTC, #debian-hurd, 2011-05-19
<pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the
"systemd as dependency" and all the messages in it don't give me a bright
future for gnome on hurd...
<pochu> yeah, I've read the thread
<pochu> it's only a proposal so far... hopefully it'll be rejected, or they
will only accept the interfaces that other OSes can implement...
<pochu> we'll see
<pinotree> you can always help me with kde on hurd, would be nice ;)
<pochu> hehe
<pinotree> pochu: well, even if the depenency is rejected, the whole «don't
give a damn about non-linux and only bless linux for the "gnome os"» is a
bit... worrying attitude
<pochu> yeah... it doesn't come from all the community though
<pochu> I'm sure some people have always thought that way
<tschwinge> Or we could get systemd going? :-)
<pochu> good luck with that :p
<guillem> tschwinge: haha!? :)
<tschwinge> That bad?
<guillem> tschwinge: if you mean by that forking indefinitely then maybe
<guillem> tschwinge: upstream has expressely stated multiple times, no
interest whatsoever in any kind of portability to anything non-Linux
<guillem> or even older Linux versions!
<guillem> to the point of rejecting patches, because they "clutter" the
source code...
<tschwinge> Well, then let's ``just'' implement the Linux interfaces. :-)
<guillem> tschwinge: then you'll be always playing catch up
<guillem> tschwinge: for example several of the Linux-only things upstream
makes heavy use of, are pretty recent Linux-only additions to the kernel,
but equivalents have been present on FreeBSD for years
<tschwinge> Yeah. I'm half-serious, half-joking.
<tschwinge> I haven't looked at the systemd code at all.
<guillem>
https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html
for a list of its dependencies
<guillem> some are just glibc extensions though
<guillem> and some are IMO optional and should be conditionalized, but...
<guillem> pochu: I don't think that attitude is that old, there was a time
when Linux was not used widely, or even that functional, I think it has
been taking strength since the Linux Plumbers Cartel started :)
<guillem> as in one thing is not caring about anything non-Linux, the other
is outright rejecting portability fixes
<guillem> tschwinge: in any case, these "recent" events are "pissing me
off" to the point of having considered several times implementing
portable replacements for some of those Utopia projects, the problem as
always is time though :)
<guillem> tschwinge: and the issue is not only with systemd, upstart's
upstream has the same approach to portability, if you want to port it,
you'll have to maintain a fork
<pochu> let's create our own init system, make it better than anyone else,
and when people start switching to it, let's start using hurd-only APIs
:)
<tschwinge> We already had someone work on that. Like ten years ago. DMD.
Daemon Managing Daemons. <http://directory.fsf.org/project/DMD/>
<guillem> the real problem with that attitude is not the lack of care for
portabilty, the real problem is that these people are pushing for their
stuff all over the stack, and most of the time deprecating their own
stuff after a while when they have rewritten it from scratch, leaving the
burden of maintaining the old stuff to the other ports
<guillem> witness HAL, ConsoleKit, etc etc
<guillem> (anyway enough ranting I guess :)
<tschwinge> Yeah, it's true, though.
<pochu> agreed
IRC, freenode, #hurd, 2013-01-18
<braunr> systemd relies on linux specific stuff that is difficult to
implement
<braunr> notably cgroups to isolate the deamons it starts so it knows when
they stopped regardless of their pid
<braunr> just assume you can't use systemd on anything else than linux
IRC, OFTC, #debian-hurd, 2013-08-12
<azeem> huh, Lennert Poettering just mentioned the Hurd in his systmd talk
<azeem> well, in the context of you IPC in Unix sucks and kdbus
<azeem> s/you/how/
<pinotree> QED
<pinotree> what did you expect? :)
<azeem> I didn't quite get it, but he seemed to imply the Hurd was a step
in the right direction over Unix
<azeem> (which is obvious, but it wasn't obvious he had that opinion)
IRC, OFTC, #debian-hurd, 2013-08-13
<azeem> so cgroups seems to be most prominent thing the systemd people
think the Hurd lacks
<tschwinge> azeem: In 2010, I came to the same conclusion,
<http://www.gnu.org/software/hurd/open_issues/systemd.html>. ;-)
<azeem> heh
<tschwinge> I don't think of any show-stopper for implementing that -- just
someone to do it.
<youpi> azeem: which part of cgroups, like being able to kill a cgroup?
<youpi> it shouldn't be very hard to implement what systemd needs
<azeem> probably also the resource allocation etc.
<azeem> the questions are I guess (i) do the cgroups semantics make sense
from our POV and/or do we accept that cgroups is the "standard" now and
(ii) should systemd require concrete implementations or just the concept
in a more abstract sense
<teythoon> being the first non Linux OS that runs systemd would be a nice
showcase of Hurds flexibility
<azeem> maybe upstart is less trouble
<pinotree> azeem: possibly
<azeem> teythoon: can you just include upstart in your GSOC? kthxbye
<pinotree> at least libnih (the library with base utilities and such used
by upstart) required a working file monitor (and the current
implementation kind of exposes a fd) and certain semantics for waitid
<pinotree> libnih/upstart have "just" the issue of being under CLA...
<azeem> pinotree: yeah, true
<azeem> I suggested "startup" as a name for a fork
<pinotree> imho there would be no strict need to fork
<teythoon> azeem: but upstart is a lot less interesting. last time I used
it it wasn't even possible to disable services in a clean way
<pochu> pinotree: is that still so now that Scott works for google?
<pinotree> pochu: yeah, since it's a Canonical CLA, not rally something
tied to a person
<pinotree> (iirc)
<pochu> sure, but scott is the maintainer...
<pochu> shrug
<azeem> nah, scott left upstart
<azeem> AFAIK
<azeem> at least James Hunt gave a talk earlier with Steve Langasek and
introduced himself as the upstart maintainer
<azeem> also I heard in the hallway track that the upstart people are
somewhat interested in BSD/Hurd support as they see it as a selling point
against systemd
<pinotree> pochu: it's just like FSF CLA for GNU projects: even if the
maintainers/contributors change altogether, copyright assignment is still
FSF
<azeem> but their accents were kinda annoying/hard to follow so I didn't
follow their talk closesly to see whether they brought it up
<azeem> pinotree: well, it's not
<pochu> azeem: looking at https://code.launchpad.net/libnih, I'm not sure
libnih has a maintainer anymore...
<azeem> pinotree: first off, you're not signing over the copyright with
their CLA, just giving them the right to relicense
<azeem> pinotree: but more importantaly, the FSF announced in a legally
binding way that they will not take things non-free
<azeem> anyway, I'll talk to the upstart guys about libnih
IRC, OFTC, #debian-hurd, 2013-08-15
<azeem> btw, I talked to vorlon about upstart and the Hurd
<azeem> so the situation with libnih is that it is basically
feature-complete, but still maintained by Scott
<azeem> upstart is leveraging it heavily
<azeem> and Scott was (back in the days) against patches for porting
<azeem> for upstart proper, Steve said he would happily take porting
patches
IRC, OFTC, #debian-hurd, 2013-11-28
<azeem> teythoon: did you see they got libnih ported to kfreebsd?
<azeem> http://lists.debian.org/debian-devel/2013/11/msg00395.html
<azeem> "I haven't started looking into Hurd yet," sounds promising
<teythoon> saw that
<teythoon> i looked at libnih too
<teythoon> wrote a mail about that
IRC, freenode, #hurd, 2013-08-26
< youpi> teythoon: I tend to agree with mbanck
< youpi> although another thing worth considering would be adding something
similar to control groups
< youpi> AIUI, it's one of the features that systemd really requires
< braunr> uhg, cgroups already
< braunr> youpi: where is that discussion ?
< youpi> it was a private mail
< braunr> oh ok
< teythoon> right, so about upstart
< teythoon> to be blunt, I do not like upstart, though my experience with
it is limited and outdated
< braunr> that was quick :)
< braunr> i assume this follows your private discussion with youpi and
mbank ?
< teythoon> I used it on a like three years old ubuntu and back then it
couldn't do stufft hat even sysvinit could do
< teythoon> there was not much discussion, mbank suggested that I could
work on upstart
< teythoon> b/c it might be easier to support than systemd
< teythoon> which might be very well true, then again what's the benefit of
having upstart? I'm really curious, I should perhaps read up on its
features
< pinotree> event-based, etc
< youpi> it is also about avoiding being pushed out just because we don't
support it?
< teythoon> yes, but otoh systemd can do amazing things, the featurelist of
upstart reads rather mondane in comparison
< youpi> I don't really have an opinion over either, apart from portability
of the code
< braunr> teythoon: the system requirements for systemd would take much
time to implement in comparison to what we already have
< braunr> i still have maksym's work on last year gsoc on my list
< braunr> waiting to push in the various libpager related patches first
< teythoon> so you guys think it's worthwile to port upstart?
< braunr> no idea
< braunr> teythoon: on another subject
< azeem_> teythoon: I like systemd more, but the hallway track at Debconf
seemed to imply most people like Upstart better except for the CLA
< azeem_> which I totally forgot to address
< youpi> CLA ?
< azeem_> contributor license agreement
< braunr> since you've now done very good progress, is your work available
in the form of ready-to-test debian packages ?
< teythoon> braunr: it is
< teythoon> braunr: http://teythoon.cryptobitch.de/gsoc/heap/debian/
< braunr> i remember urls in some of your mails
< braunr> ah thanks
< braunr> "cryptobitch" hum :)
< azeem_> in any case, everbody assumed either Upstart or Systemd are way
ahead of systemvinit
< braunr> sysvinit is really ancient :)
< azeem_> apart from the non-event-driven fundamental issue, a lot of
people critized that the failure rate at writing correct init-scripts
appears to be too high
< azeem_> one of the questions brought up was whether it makes sense to
continue to ship/support systemvinit once a switch is made to
systemd/upstart for the Linux archs
< azeem_> systemvinit scripts might bitrot
< azeem_> but anyway, I don't see a switch happen anytime soon
< teythoon> well, did upstart gain the capability of disabling a service
yet?
< azeem_> teythoon: no idea, but apparently:
http://askubuntu.com/questions/19320/recommended-way-to-enable-disable-services/20347#20347
< teythoon> azeem_: then there is hope yet ;)
< azeem_> the main selling point of Upstart is that it shipped in several
LTS releases and is proven technology (and honestly, I don't read a lot
of complaints online about it)
< azeem_> (I don't agree that SystemD is unproven, but that is what the
Upstart guys implied)
< teythoon> am I the only one that thinks that upstart is rather
unimpressive?
* azeem_ doesn't have an opinion on it
< azeem> teythoon:
http://penta.debconf.org/dc13_schedule/events/1027.en.html has slides and
the video
< azeem> teythoon: eh, appears the link to the slides is broken, but they
are here:
http://people.canonical.com/~jhunt/presentations/debconf13/upstart-debconf-2013.pdf
< braunr> teythoon: actually, from the presentation, i'd tend to like
upstart
< braunr> dependency, parallelism and even runlevel compatibility flows
naturally from the event based model
< braunr> sysv compatibility is a great feature
< braunr> it does look simple
< braunr> i admit it's "unimpressive" but do we want an overkill init
system ?
< braunr> teythoon: what makes you not like it ?
< azeem> Lennart critized that upstart doesn't generate events, just
listens to them
< azeem> (which is a feature, not a bug to some)
< braunr> azeem: ah yes, that could be a lack
< azeem> braunr: http://penta.debconf.org/dc13_schedule/events/983.en.html
was the corresponding SystemD talk by Lennart, though he hasn't posted
slides yet I think
< teythoon> braunr: well, last time I used it it was impossible to cleanly
disable a service
< teythoon> also ubuntu makes such big claims about software they develop,
and when you read up on them it turns out that most of the advertised
functionality will be implemented in the near future
< teythoon> then they ship software as early as possible only to say later
that is has proven itself for so many years
< teythoon> and tbh I hate to be the one that helped port upstart to hurd
(and maybe kfreebsd as a byproduct) and later debian choses upstart over
systemd b/c it is available for all debian kernels
< kilobug> teythoon: ubuntu has a tendency to ship software too early when
it's not fully mature/stable, but that doesn't say anything about the
software itself
< pinotree> teythoon: note the same is sometimes done on fedora for young
technologies (eg systemd)
< azeem> teythoon: heh, fair enough
< p2-mate> braunr: I would prefer if my init doesn't use ptrace :P
< teythoon> p2-mate: does upstart use ptrace?
< p2-mate> teythoon: yes
< teythoon> well, then I guess there won't be an upstart for Hurd for some
time, no?
< kilobug> p2-mate: why does it use ptrace for ?
< p2-mate> kilobug: to find out if a daemon forked
< kilobug> hum I see
< azeem> p2-mate: the question is whether there's a Hurdish way to
accomplish the same
< p2-mate>
http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head:/init/job_process.c
< p2-mate> see job_process_trace_new :)
< kilobug> azeem: it doesn't seem too complicated to me to have a way to
get proc notify upstart of forks
< p2-mate> azeem: that's a good question. there is a linuxish way to do
that using cgroups
< azeem> right, there's a blueprint suggesting cgroups for Upstart here:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations
< teythoon> yes, someone should create a init system that uses cgroups for
tracking child processes >,<
< teythoon> kilobug: not sure it is that easy. who enforces that proc_child
is used for a new process? isn't it possible to just create a new mach
task that has no ties to the parent process?
< teythoon> azeem: what do you mean by "upstart does not generate events"?
there are "emits X" lines in upstart service descrpitions, surely that
generates event X?
< azeem> I think the critique is that this (and those upstart-foo-bridges)
are bolted on, while SystemD just takes over your systems and "knows"
about them first-hand
< azeem> but as I said, I'm not the expert on this
< teythoon> uh, in order to install upstart one has to remove sysvinit
("yes i am sure...") and it fails to bring up the network on booting the
machine
< teythoon> also, both systemd and upstart depend on dbus, so no cookie for
us unless that is fixed first, right?
< pinotree> true
< teythoon> well, what do you want me to do for the next four weeks?
< youpi> ideally you could make both upstart and systemd work on hurd-i"86
< pinotree> both in 4 weeks?
< youpi> so hurd-i386 doesn't become the nasty guy that makes people tend
for one or the other
< youpi> I said "ideally"
< youpi> I don't really have any idea how much work is required by either
of the two
< youpi> I'd tend to think the important thing to implement is something
similar to control groups, so both upstart (which is supposed to use them
someday) and systemd can be happy about it
< teythoon> looks like upstarts functionality depending on ptrace is not
required, but can be enabled on a per service base
< teythoon> so a upstart port that just lacks this might be possible
< teythoon> youpi: the main feature of cgroups is that a process cannot
escape its group, no? i'm not sure how this could be implemented atop of
mach in a secure and robust way
< teythoon> b/c any process can just create mach tasks
< youpi> maybe we need to add a feature in mach itself, yes
< teythoon> ok, implementing cgroups sounds fun, I could do that
< youpi> azeem: are you ok with that direction?
< azeem> well, in general yes; however, AIUI, cgroups is being redesigned
upstream, no?
< youpi> that's why I said "something like cgroups"
< azeem> ah, ok
< youpi> we can do something simple enough to avoid design quesetions, and
that would still be enough for upstart & systemd
< azeem>
(http://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign)
btw
< braunr> p2-mate: upstart uses ptrace ?
< p2-mate> yes
< youpi> teythoon: and making a real survey of what needs to be fixed for
upstart & systemd
< p2-mate> see my link posted earlier
< braunr> ah already answered
< braunr> grmbl
< braunr> it's a simple alternative to cgroups though
< braunr> teythoon: dbus isn't a proble
< braunr> problem
< braunr> it's not that hard to fix
< youpi> well, it hasn't been fixed for a long time now :)
< braunr> we're being slow, that's all
< braunr> and interested by other things
< gg0> 12:58 < teythoon> btw, who is this heroxbd fellow and why has he
suddenly taken interest in so many debian gsoc projects?
< gg0> http://lists.debian.org/debian-hurd/2013/05/msg00133.html
< gg0> i notice nobody mentioned openrc
< pinotree> he's the debian student working on integrating openrc
< gg0> pinotree: no, the student is Bill Wang, Benda as he says is a
co-mentor
https://wiki.debian.org/SummerOfCode2013/Projects#OpenRC_init_system_in_Debian
< pinotree> whatever, it's still the openrc gsoc
< azeem> well, they wanted to look at it WRT the Hurd, did they follow-up
on this?
< gg0> btw wouldn't having openrc on hurd be interesting too?
< pinotree> imho not really
< gg0> no idea whether Bill is also trying to figure out what to do,
probably not
< azeem> somebody could ping that thread you mentioned above to see whether
they looked at the Hurd and/or need help/advice
< gg0> azeem: yeah somebody who could provide such help/advice. like.. you?
for instance
* gg0 can just paste urls
< azeem> they should just follow-up on-list
IRC, freenode, #hurd, 2013-08-28
<teythoon> anyone knows a user of cgroups that is not systemd? so far I
found libcg, that looks like a promising first target to port first,
though not surprisingly it is also somewhat linux specific
<taylanub> teythoon: OpenRC optionally uses cgroups IIRC.
<taylanub> Not mandatory because unlike systemd it actually tries (at all)
to be portable.
IRC, freenode, #hurd, 2013-09-02
<teythoon> braunr: I plan to patch gnumach so that the mach tasks keep a
reference to the task that created them and to make that information
available
<teythoon> braunr: is such a change acceptable?
<braunr> teythoon: what for ?
<teythoon> braunr: well, the parent relation is currently only implemented
in the Hurd, but w/o this information tracked by the kernel I don't see
how I can prevent malicious/misbehaving applications to break out of
cgroups
<teythoon> also I think this will enable us to fix the issue with tracking
which tasks belong to which subhurd in the long term
<braunr> ah cgroups
<braunr> yes cgroups should partly be implemented in the kernel ...
<braunr> teythoon: that doesn't surprise me
<braunr> i mean, i think it's ok
<braunr> the kernel should implement tasks and threads as closely as the
hurd (or a unix-like system) needs it
<teythoon> braunr: ok, cool
<teythoon> braunr: I made some rather small and straight forward changes to
gnumach, but it isn't doing what I thought it would do :/
<teythoon> braunr: http://paste.debian.net/33717/
<braunr> you added a field to task_basic_info
<braunr> thereby breaking the ABI
<teythoon> braunr: my small test program says: my task port is 1(pid 13)
created by task -527895648; my parent task is 31(pid 1)
<teythoon> braunr: no, it is not. I appended a field and these structures
are designed to be extendable
<braunr> hm
<braunr> ok
<braunr> although i'm not so sure
<braunr> there are macros defining the info size, depending on what you ask
<braunr> you may as well get garbage
<braunr> have you checked that ?
<teythoon> i initialized my struct to zero before calling mach
<braunr> teythoon: can you put some hardcoded value, just to make sure data
is correctly exported ?
<teythoon> braunr: right, good idea
<teythoon> braunr: my task port is 1(pid 13) created by task 3; my parent
task is 31(pid 1) -- so yes, hardcoding 3 works
<braunr> ok
<teythoon> braunr: also I gathered evidence that the convert_task_to_port
thing works, b/c first I did not have the task_reference call just before
that so the reference count was lowered (convert... consumes a reference)
and the parent task was destroyed
<teythoon> braunr: I must admit I'm a little lost. I tried to return a
reference to task rather than task->parent_task, but that didn't work
either
<teythoon> braunr: I feel like I'm missing something here
<teythoon> maybe I should get aquainted with the kernel debugger
<teythoon> err, the kernel debugger is not accepting any symbol names, even
though the binary is not stripped o_O
<teythoon> err, neither the kdb nor gdb attached to qemu translates
addresses to symbols, gdb at least translates symbols to addresses when
setting break points
<teythoon> how did anyone ever debug a kernel problem under these
conditions?
<braunr> teythoon: i'll have a look at it when i have some time
IRC, freenode, #hurd, 2013-09-03
<teythoon> :/ I believe the startup_notify interface is ill designed... an
translator can defer the system shutdown indefinitely
<braunr> it can
<teythoon> that's bad
<braunr> yes
<braunr> the hurd has a general tendency to trust its "no mutual trust
required" principle
<braunr> to rely on it a bit too much
<teythoon> well, at least it's a privileged operation to request this kind
of notification, no?
<braunr> why ?
<braunr> teythoon: it normally is used mostly by privileged servers
<braunr> but i don't think there is any check on the recipient
<teythoon> braunr: b/c getting the port to /hurd/init is done via
proc_getmsgport
<braunr> teythoon: ?
<teythoon> braunr: well, in order to get the notifications one needs the
msgport of /hurd/init and getting that requires root privileges
<braunr> teythoon: oh ok then
<braunr> teythoon: what's bad with it then ?
<teythoon> braunr: even if those translators are somewhat trusted, they can
(and do) contain bugs and stall the shutdown
<teythoon> I think this even happened to me once, I think it was the pfinet
translator
<braunr> teythoon: how do you want it to behave instead ?
<teythoon> braunr: well, /hurd/init notifies the processes sequentially,
that seems suboptimal, better to send async notifications to all of them
and then to collect all the answers
<teythoon> braunr: if one fails to answer within a rather large time frame
(say 5 minutes) shutdown anyway
<braunr> i agree with async notifications but
<braunr> i don't agree with the timeout
<teythoon> for reference, a (voluntary) timeout of 1 minute is hardcoded in
/hurd/init
<braunr> the timeout should be a parameter
<braunr> it's common on large machines to have looong shutdown delays
<teythoon> of the notification?
<braunr> the answer means "ok i'm done you can shutdown"
<braunr> well this can take long
<braunr> most often, administrators simply prefer to trust their program is
ok and won't take longer than it needs to, even if it's long
<teythoon> and not answering at all causes the shutdown / reboot to fail
making the system hang
<braunr> i know
<teythoon> in a state where it is not easily reached if you do not have
access to it
<braunr> but since it only concerns essential servers, it should befine
<braunr> essential servers are expected to behave well
<teythoon> it concerns servers that have requested a shutdown notification
<braunr> ok so no essential but system servers
<teythoon> essential servers are only exec, proc, /
<teythoon> yes
<braunr> the same applies
<pinotree> init and auth too, no?
<teythoon> yes
<braunr> you expect root not to hang himself
<teythoon> I do expect all software to contain bugs
<braunr> yes but you also expect them to provide a minimum level of
reliability
<braunr> otherwise you can just throw it all away
<teythoon> no, not really
<braunr> well
<teythoon> I know, that's my dilemma basically ;)
<braunr> if you don't trust your file system, you make frequent backups
<braunr> if you don't trust your shutdown code, you're ready to pull the
plug manually
<braunr> (or set a watchdog or whatever)
<braunr> what i mean is
<braunr> we should NEVER interfere with a program that is actually doing
its job just because it seems too long
<braunr> timeouts are almost never the best solution
<braunr> they're used only when necessary
<braunr> e.g. across networks
<braunr> it's much much much worse to interrupt a proper shutdown process
because it "seems too long" than just trust it behaves well 99999%%%% of
the time
<braunr> in particular because this case deals with proper data flushing,
which is an extremely important use case
<teythoon> it's hard/theoretically impossible to distinguish between taking
long and doing nothing
<braunr> it's impossible
<braunr> agreed
<braunr> => trust
<braunr> if you don't trust, you run real time stuff
<braunr> and you don't flush data on disk
<teythoon> ^^
<braunr> (which makes a lot of computer uses impossible as well)
<teythoon> there are only 2 people I trust, and the other one is not
/hurd/pfinet
<braunr> if this shutdown procedure is confined to the TCB, it's fine to
trust it goes well
<teythoon> tcb?
<braunr> trusted computing base
<braunr> http://en.wikipedia.org/wiki/Trusted_computing_base
* teythoon shudders
<teythoon> "trust" is used way to much these days
<teythoon> and I do not like the linux 2.0 ip stack to be part of our TCB
<braunr> basically, on a multiserver system like the hurd, the tcb is every
server on the path to getting a service done from a client
<braunr> then make it not request to be notified
<braunr> or make two classes of notifications
<braunr> because unprivileged file systems should be notified too
<teythoon> indeed
<teythoon> by the way, we should have a hurdish libnotify or something for
this kind of notifications
<braunr> but in any case, it should really be policy
<braunr> we should ... :)
<teythoon> ^^
IRC, freenode, #hurd, 2013-09-04
<teythoon> braunr: btw, I now believe that no server that requested
shutdown notifications can stall the shutdown for more than 1 minute
*unless* its message queue is full
<teythoon> so any fs should better sync within that timeframe
<braunr> where is this 1 min defined ?
<teythoon> init/init.c search for 60000
<braunr> ew
<teythoon> did I just find the fs corruption bug everyone was looking for?
<braunr> no
<braunr> what corruption bug ?
<teythoon> not sure, I thought there was still some issues left with
unclean filesystems every now and then
<teythoon> *causing
<braunr> yes but we know the reasons
<teythoon> ah
<braunr> involving some of the funniest names i've seen in computer
terminology :
<braunr> writeback causing "message floods", which in turn create "thread
storms" in the servers receiving them
<teythoon> ^^ it's usually the other way around, storms causing floods >,,
<braunr> teythoon: :)
<braunr> let's say it's a bottom-up approach
<teythoon> then the fix is easy, compile mach with -DMIGRATING_THREADS :)
<braunr> teythoon: what ?
<teythoon> well, that would solve the flood/storm issue, no?
<braunr> no
<braunr> the real solution is proper throttling
<braunr> which can stem from synchronous rpc (which is the real property we
want from migrating threads)
<braunr> but the mach writeback interface is async
<braunr> :p
IRC, freenode, #hurd, 2013-09-05
<braunr> teythoon: oh right, forgot about your port issue
<teythoon> don't worry, I figured by now that this must be a pointer
<teythoon> and I'm probably missing some magic that transforms this into a
name for the receiver
<teythoon> (though I "found" this function by looking at the mig
transformation for ports)
<braunr> i was wondering why you called the convert function manually
<braunr> instead of simply returning the task
<braunr> and let mig do the magic
<teythoon> b/c then I would have to add another ipc call, no?
<braunr> let me see the basic info call again
<braunr> my problem with this code is that it doesn't take into account the
ipc space of the current task
<braunr> which means you probably really return the ipc port
<braunr> the internal kernel address of the struct
<braunr> indeed, ipc_port_t convert_task_to_port(task)
<braunr> i'd personally make a new rpc instead of adding it to basic info
<braunr> basic info doesn't create rights
<braunr> what you want to achieve does
<braunr> you may want to make it a special port
<braunr> i.e. a port created at task creation time
<teythoon> y?
<braunr> it also means you need to handle task destruction and reparent
<teythoon> yes, I thought about that
<braunr> see
http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
<braunr> for now you may simply turn the right into a dead name when the
parent dies
<braunr> although adding a call and letting mig do it is simpler
<braunr> mig handles reference counting, users just need to task_deallocate
once done
<teythoon> o_O mig does reference counting of port rights?
<braunr> mig/mach_msg
<teythoon> is there anything it *doesn't* do?
<braunr> i told you, it's a very complicated messaging interface
<braunr> coffee ?
<braunr> fast ?
<teythoon> ^^
<braunr> mig knows about copy_send/move_send/etc...
<braunr> so even if it doesn't do reference counting explicitely, it does
take care of that
<teythoon> true
<braunr> in addition, the magic conversions are intended to both translate
names into actual structs, and add a temporary reference at the same time
<braunr> teythoon: everything clear now ? :)
<teythoon> braunr: no, especially not why you suggested to create a special
port. but this will have to wait for tomorrow ;)
IRC, OFTC, #debian-hurd, 2013-09-06
<vorlon> teythoon: hi there
<vorlon> so I've been following your blog entries about cgroups on
hurd... very impressive :)
<vorlon> but I think there's a misunderstanding about upstart and
cgroups... your "conjecture" in
https://teythoon.cryptobitch.de/posts/what-will-i-do-next-cgroupfs-o/ is
incorrect
<vorlon> cgroups does not give us the interfaces that upstart uses to
define service readiness; adding support for cgroups is interesting to
upstart for purposes of resource partitioning, but there's no way to
replace ptrace with cgroups for what we're doing
<teythoon> vorlon: hi and thanks for the fish :)
<teythoon> vorlon: what is it exactly that upstart is doing with ptrace
then?
<teythoon> .,oO( your nick makes me suspicious for some reason... ;)
<teythoon> service readiness, what does that mean exactly?
<vorlon> teythoon: so upstart uses ptrace primarily for determining service
readiness. The idea is that traditionally, you know an init script is
"done" when it returns control to the parent process, which happens when
the service process has backgrounded/daemonized; this happens when the
parent process exits
<vorlon> in practice, however, many daemons do this badly
<vorlon> so upstart tries to compensate, by not just detecting that the
parent process has exited, but that the subprocess has exited
<vorlon> (for the case where the upstart job declares 'expect daemon')
<vorlon> cgroups, TTBOMK, will let you ask "what processes are part of this
group" and possibly even "what process is the leader for this group", but
doesn't really give you a way to detect "the lead process for this group
has changed twice"
<vorlon> now, it's *better* in an upstart/systemd world for services to
*not* daemonize and instead stay running in the foreground, but then
there's the question of how you know the service is "ready" before moving
on to starting other services that depend on it
<vorlon> systemd's answer to this is socket-based activation, which we
don't really endorse for upstart for a variety of reasons
<teythoon> hm, okay
<teythoon> so upstart does this only if expect daemon is declared in the
service description?
<vorlon> (in part because I've seen security issues when playing with the
systemd implementation on Fedora, which Lennart assures me are
corner-cases specific to cups, but I haven't had a chance to test yet
whether he's right)
<teythoon> and it is not used to track children, but only to observe the
daemonizing process?
<vorlon> yes
<teythoon> and it then detaches from the processes?
<vorlon> yes
<vorlon> once it knows the service is "ready", upstart doesn't care about
tracking it; it'll receive SIGCHLD when the lead process dies, and that's
all it needs to know
<teythoon> ok, so I misunderstood the purpose of the ptracing, thanks for
clarifying this
<vorlon> my pleasure :)
<vorlon> I realize that doesn't really help with the problem of hurd not
having ptrace
<teythoon> no, but thanks anyway
<vorlon> fwiw, the alternative upstart recommends for detecting service
readiness is for the process to raise SIGSTOP when it's ready
<vorlon> doesn't require ptracing, doesn't require socket-based activation
definitions; does require the service to run in a different mode than
usual where it will raise the signal at the correct time
<teythoon> right, but that requires patching it, same as the socket
activation stuff of systemd
<vorlon> (this is upstart's 'expect stop')
<vorlon> yes
<vorlon> though at DebConf, there were some evil ideas floating around
about doing this with an LD_PRELOAD or similar ;)
<vorlon> (overriding 'daemonize')
<vorlon> er, 'daemon()'
<teythoon> ^^
<vorlon> and hey, what's suspicious about my /nick? vorlons are always
trustworthy
<vorlon> ;)
<teythoon> sure they are
<teythoon> but could this functionality be reasonably #ifdef'ed out for a
proof of concept port?
<vorlon> hmm, you would need to implement some kind of replacement... if
you added cgroups support to upstart as an alternative
<vorlon> that could work
<vorlon> i.e., you would need upstart to know when the service has exited;
if you aren't using ptrace, you don't know the "lead pid" to watch for,
so you need some other mechanism --> cgroups
<vorlon> and even then, what do you do for a service like openssh, which
explicitly wants to leave child processes behind when it restarts?
<teythoon> right...
<vorlon> oh, I was hoping you knew the answer to this question ;) Since
AFAICS, openssh has no native support for cgroups
<teythoon> >,< I don't, but I'll think about what you've said... gotta go,
catch what's left of the summer ;)
<teythoon> fwiw I consider fork/exec/the whole daemonizing stuff fubar...
<teythoon> see you around :)
<vorlon> later :)
IRC, OFTC, #debian-hurd, 2013-09-07
<teythoon> vorlon: I thought about upstarts use of ptrace for observing the
daemonizing process and getting hold of the child
<teythoon> vorlon: what if cgroup(f)s would guarantee that the order of
processes listed in x/tasks is the same they were added in?
<teythoon> vorlon: that way, the first process in the list would be the
daemonized child after the original process died, no?
<vorlon> teythoon: that doesn't tell you how many times the "lead" process
has changed, however
<vorlon> you need synchronous notifications of the forks in order to know
that, which currently we only get via ptrace
IRC, OFTC, #debian-hurd, 2013-09-08
<teythoon> vorlon: ok, but why do the notifications have to be synchronous?
does that imply that the processes need to be stopped until upstart does
something?
<vorlon> teythoon: well, s/synchronous/reliable/
<vorlon> you're right that it doesn't need to be synchronous; but it can't
just be upstart polling the status of the cgroup
<vorlon> because processes may have come and gone in the meantime
<teythoon> vorlon: ok, cool, b/c the notifications of process changes I'm
hoping to introduce into the proc server for my cgroupfs do carry exactly
this kind of information
<vorlon> cool
<vorlon> are you discussing an API for this with the Linux cgroups
maintainers?
<teythoon> otoh it would be somewhat "interesting" to get upstart to use
this b/c of the way the mach message handling is usually implemented
<vorlon> :)
<teythoon> no, I meant in order for me to be able to implement cgroupfs I
had to create these kind of notifications, it's not an addition to the
cgroups api
<teythoon> is upstart multithreaded?
<vorlon> no
<vorlon> threads are evil ;)
<teythoon> ^^ I mostly agree
<vorlon> it uses a very nice event loop, leveraging signalfd among other
things
<teythoon> uh oh, signalfd sounds rather Linuxish
<pinotree> it is
<vorlon> I think xnox mentioned when he was investigating it that kfreebsd
now also supports it
<vorlon> but yeah, AFAIK it's not POSIX
<pinotree> it isn't, yes
<vorlon> but it darn well should be
<vorlon> :)
<vorlon> it's the best improvement to signal handling in a long time
<teythoon> systemd also uses signalfd
<teythoon> umm, it seems I was wrong about Hurd not having ptrace, the wiki
suggests that we do have it
<pinotree> FSVO "have"
<teythoon> ^^
<xnox> vorlon: teythoon: so ok kFreeBSD/FreeBSD ideally I'd be using
EVFILT_PROC from kevent which allows to receive events & track: exit,
fork, exec, track (follow across fork)
<xnox> upstart also uses waitid()
<xnox> so a ptrace/waitid should be sufficient to track processes, if Hurd
has them.
IRC, freenode, #hurd, 2013-09-09
<youpi> teythoon: yes, the shutdown notifications do stall the process
<youpi> but no more than a minute, or so
<youpi> teythoon: btw, did you end up understanding the odd thing in
fshelp_start_translator_long?
<youpi> I haven't had the time to have a look
<teythoon> youpi: what odd thing? the thing about being implemented by hand
instead of using the mig stub?
<youpi> the thing about the port being passed twice
<youpi> XXX this looks wrong to me, please have a look
<youpi> in the mach_port_request_notification call
<teythoon> ah, that was alright, yes
<youpi> ok
<youpi> so I can drop it from my TODO :)
<teythoon> this is done on the control port so that a translator is
notified if the "parent" translator dies
<teythoon> was that in fshelp_start_translator_long though? I thought that
was somewhere else
<youpi> that's what the patch file says
<youpi> +++ b/libfshelp/start-translator-long.c
<youpi> @@ -293,6 +293,7 @@ fshelp_start_translator_long (fshelp_open_fn_t
underlying_open_fn,
<youpi> + /* XXX this looks wrong to me, bootstrap is used twice as
argument... */
<youpi> bootstrap,
MACH_NOTIFY_NO_SENDERS, 0,
<teythoon> right
<teythoon> I remember that when I got a better grip of the idea of
notifications I figured that this was indeed okay
<teythoon> I'll have a quick look though
<youpi> ok
<teythoon> ah, I remember, this notifies the parent translator if the child
dies, right
<teythoon> and it is a NO_SENDERS notification, so it is perfectly valid to
use the same port twice, as we only hold a receive right
IRC, freenode, #hurd, 2013-09-10
<teythoon> braunr: are pthreads mapped 1:1 to mach threads?
<braunr> teythoon: yes
<teythoon> I'm reading the Linux cgroups "documentation" and it talks about
tasks (Linux threads) and thread group IDs (Linux processes) and I'm
wondering how to map this accurately onto Hurd concepts...
<teythoon> apparently on Linux there are PIDs/TIDs that can be used more or
less interchangeably from userspace applications
<teythoon> the Linux kernel however knows only PIDs, and each thread has
its own, and those threads belonging to the same (userspace) PID have the
same thread group id
<teythoon> aiui on Mach threads belong to a Mach task, and there is no
global unique identifier exposed for threads, right?
<teythoon> braunr: ^
<tschwinge> teythoon: There is its thread port, which in combination with
its task port should make it unique? (I might be missing context.)
<tschwinge> Eh, no. The task port's name will only locally be unique.
* tschwinge confused himself.
<teythoon> tschwinge, braunr: well, the proc server could of course create
TIDs for threads the same way it creates PIDs for tasks, but that should
probably wait until this is really needed
<teythoon> for the most part, the tasks and cgroup.procs files contain the
same information on Linux, and not differentiating between the two just
means that cgroupfs is not able to put threads into cgroups, just
processes
<teythoon> that might be enough for now
IRC, freenode, #hurd, 2013-09-11
<teythoon> ugh, some of the half-backed Linux interfaces will be a real
pain in the ass to support
<teythoon> they do stuff like write(2)ing file descriptors encoded as
decimal numbers for notifications :-/
<braunr> teythoon: for cgroup ?
<teythoon> braunr: yes, they have this eventfd based notification mechanism
<teythoon> braunr: but I fear that this is a more general problem
<braunr> do we need eventfd ?
<teythoon> I mean passing FDs around is okay, we can do this just fine with
ports too, but encoding numbers as an ascii string and passing that
around is just not a nice interface
<braunr> so what ?
<teythoon> it's not a designed interface, it's one people came up with b/c
it was easy to implement
<braunr> if it's meant for compatibility, that's ok
<teythoon> how would you implement this then? as a special case in the
write(2) implementation in the libc? that sounds horrible but I do hardly
see another way
<teythoon> ok, some more context: the cgroup documentation says
<teythoon> write "<event_fd> <control_fd> <args>" to cgroup.event_control.
<teythoon> where event_fd is the eventfd the notification should be sent to
<pinotree> theorically they could have used sendmsg + a custom payload
<teythoon> control_fd is an fd to the pseudo file one wants notifications
for
<teythoon> yes, they could have, that would have been nicer to implement
<teythoon> but this...
IRC, freenode, #hurd, 2013-09-12
<teythoon> ugh, gnumachs build system drives me crazy %-/
<pinotree> oh there's worse than that
<teythoon> I added a new .defs file, did as Makerules.mig.am told me to do,
but it still does not create the stubs I need
<braunr> teythoon: gnumach doesn't
<braunr> teythoon: glibc does
<braunr> well, gnumach only creates the stubs it needs
<braunr> teythoon: you should perhaps simply use gnumach.defs
<teythoon> braunr: sure it does, e.g. vm/memory_object_default.user.c
<braunr> teythoon: what are you trying to add ?
<teythoon> braunr: I was trying to add a notification mechanism for new
tasks
<teythoon> b/c now the proc server has to query all task ports to discover
newly created tasks, this seems wasteful
<teythoon> also if the proc server could be notified on task creation, the
parent task is still around, so the notification can carry a reference to
it
<teythoon> that way gnumach wouldn't have to track the relationship, which
would create all kind of interesting questions, like whether tasks would
have to be reparented if the parent dies
<braunr> teythoon: notifications aren't that simple either
<teythoon> y not?
<braunr> 1/ who is permitted to receive them
<braunr> 2/ should we contain them to hurd systems ? (e.g. should a subhurd
receive notifications concerning tasks in other hurd systems ?)
<teythoon> that's easy imho. 1/ a single process that has a host_priv
handle is able to register for the notifications once
<braunr> what are the requirements so cgroups work as expected concerning
tasks ?
<braunr> teythoon: a single ?
<teythoon> i.e. the first proc server that starts
<braunr> then how will subhurd proc servers work ?
<teythoon> 2/ subhurds get the notifications from the first proc server,
and only those that are "for them"
<braunr> ok
<braunr> i tend to agree
<braunr> this removes the ability to debug the main hurd from a subhurd
<teythoon> this way the subhurds proc server doesn't even have to have the
host_priv porsts
<teythoon> yes, but I see that as a feature tbh
<braunr> me too
<braunr> and we can still debug the subhurd from the main
<teythoon> it still works the other way around, so it's still...
<teythoon> yes
<braunr> what would you include in the notification ?
<teythoon> a reference to the new task (proc needs that anyway) adn one to
the parent task (so proc knows what the parent process is and/or for
which subhurd it is)
<braunr> ok
<braunr> 17:21 < braunr> what are the requirements so cgroups work as
expected concerning tasks ?
<braunr> IOW, why is the parental relation needed ?
<braunr> (i don't know much about the details of cgroup)
<teythoon> well, currently we rely on proc_child to build this relation
<teythoon> but any task can use task_create w/o proc_child
<teythoon> until one claims a newly created task with proc_child, its
parent is pid 1
<braunr> that's about the hurd
<braunr> i'm rather asking about cgroups
<teythoon> ah
<teythoon> the child process has to end up in the same cgroup as the parent
<braunr> does a cgroup include its own pid namespace ?
<teythoon> not quite sure what you mean, but I'd say no
<teythoon> do you mean pid namespace as in the Linux sense of that phrase?
<teythoon> cgroups group processes(threads) into groups
<teythoon> on Linux, you can then attach controllers to that, so that
e.g. scheduling decisions or resource restrictions can be applied to
groups
<teythoon> braunr: http://paste.debian.net/38950/
<braunr> teythoon: ok so a cgroup is merely a group of processes supervised
by a controller
<braunr> for resource accounting/scheudling
<braunr> teythoon: where does dev_pager.c do the same ?
<teythoon> braunr: yes. w/o such controllers cgroups can still be used for
subprocess tracking
<teythoon> braunr: well, dev_pager.c uses mig generated stubs from
memory_object_reply.defs
<braunr> ah memory_object_reply ok
<braunr> teythoon: have you tried adding it to EXTRA_DIST ?
<braunr> although i don't expect it will change much
<braunr> teythoon: hum, you're not actually creating client stubs
<braunr> create a kern/task_notify.cli file
<braunr> as it's done with device/memory_object_reply.cli
<braunr> see #define KERNEL_USER 1
<teythoon> braunr: right, thanks :)
IRC, freenode, #hurd, 2013-09-13
<teythoon> hm, my notification system for newly created tasks kinda works
<teythoon> as in I get notified when a new task is created
<teythoon> but the ports for the new task and the parent that are carried
in the notification are both MACH_PORT_DEAD
<teythoon> do I have to add a reference manually before sending it?
<teythoon> that would make sense, the mig magic transformation function for
task_t consumes a reference iirc
<braunr> ah yes
<braunr> that reference counting stuff is some hell
<teythoon> braunr: ah, there's more though, the mig transformations are
only done in the server stub, not in the client, so I still have to
convert_task_to_port myself afaics
<teythoon> awesome, it works :)
<braunr> :)
<teythoon> ugh, the proc_child stuff is embedded deep into libc and signal
handling stuff...
<teythoon> "improving" the child_proc stuff with my shiny new notifications
wrecks havoc on the system
IRC, freenode, #hurd, 2014-01-03
<gg0> openrc on debian
https://buildd.debian.org/status/package.php?p=openrc&suite=experimental
<braunr> gg0: ah nice
IRC, freenode, #hurd, 2014-01-11
<gnu_srs1> teythoon: is the Hurd boot now fully init compatible? I would
like to try to boot with a ported openrc in a sandbox kvm:P
IRC, freenode, #hurd, 2014-01-12
<teythoon> gnu_srs1: yes, go ahead
<teythoon> gnu_srs1: you'll have to switch to sysvinit first
<teythoon> for that, you need patched sysvinit packages
<gnu_srs> teythoon: do you mean the parches in #721917?
<teythoon> gnu_srs: yes, mostly, but there is one final patch missing
<gg0> uploading patched sysvinit to debian-ports? (or braunr's or
teythoon's repos)
<teythoon> gg0, gnu_srs: they are actually here
http://teythoon.cryptobitch.de/gsoc/heap/debian/ but outdated
<gnu_srs> teythoon: if the sysvinit patches are outdated, can you update
them please? and provide a package for upload to -ports (as gg0 proposed)
<teythoon> gnu_srs: i will
<gnu_srs> tks:)
IRC, freenode, #hurd, 2014-01-13
<teythoon> gnu_srs: i updated the sysvinit patches
<teythoon> gnu_srs: for your convenience, here are packages:
https://darnassus.sceen.net/~teythoon/heap/sysvinit/
<teythoon> gnu_srs: you have to install the sysvinit-core package first,
then the others
<teythoon> to switch to sysvinit, do update-alternatives --config runsystem
and select runsystem.sysv
<teythoon> then, do reboot-hurd and hope for the best ;)
<gnu_srs> teythoon: thanks, will try soon. Are you submitting the updated
patches to #721917 too?
<teythoon> gnu_srs: i already did
<gnu_srs> good;-)
<gnu_srs> teythoon: rebooted with sysv:http://paste.debian.net/75925/
<teythoon> gnu_srs: please, whenever you run into a problem, give more
context
<teythoon> which file are you talking about ?
<teythoon> also, as the postinst script advised you, you need to use
{halt,reboot}-hurd *whenever* you switch the runsystem
<teythoon> not doing so wont do any harm, but it wont work
<teythoon> shutdown: /run/initctl: No such file or directory <-- that's
what happens if you run reboot (=reboot-sysv) w/o sysvinit being run
<teythoon> if you don't get a getty on the console, check /etc/inittab
<gnu_srs> I did note see a message from any posinst script about
{halt,reboot}-hurd, only LC* related messages
<gnu_srs> A I missed it: You must use halt-hurd or reboot-hurd to halt or
reboot the
<gnu_srs> system whenever you change the runsystem.
<gnu_srs> I don't see anything suspicious in /etc/inittab,
eg. 1:2345:respawn:/sbin/getty 38400 tty1 is there
<teythoon> 7:2345:respawn:/sbin/getty 38400 console
<teythoon> then, you'll get a getty on the mach console, even if the
hurd-console does not start
<gnu_srs> teythoon: with 7:2345:respawn:/sbin/getty 38400 console in
/etc/inittab I get a (mach) console.
<gnu_srs> never seen that mentioned anywhere
<gnu_srs> anyway, the image is now booted with sysvinit. next to try will
be openrc:P
<teythoon> gnu_srs: you haven't heard of the inittab entry for the mach
console before b/c the inittab was not used before on the hurd
<teythoon> i should probably write that down in the wiki somewhere...
<youpi> shouldn't the upgrade of the sysvinit package do it too?
<youpi> (does it at least install a correct version on newer installs?)
<teythoon> it probably should / i'm not sure
IRC, freenode, #hurd, 2014-01-13
<teythoon> gnu_srs: have you ported openrc already ?
<gnu_srs> I made it build (with temporary workarounds for PATH_MAX) but
need to change at least one file to be hurd-specific before trying to
boot
<teythoon> cool :)
<gg0> i guess not much different from http://paste.debian.net/plain/75893/
<gg0> (i didn't say it sucks but one can find it out by taking a look)
<gnu_srs> gg0: Have you talked to zigo in #openrc?. He has partial patches
(submitted to the debian repo), you do and me too.
<gnu_srs> Maybe we should align our work.
<gnu_srs> The file to make Hurd-specific is: init.sh.GNU (you start with
copy of the Linux version, I start from a copy of the BSD version).
<gnu_srs> BTW: I don't think fstabinfo is available for GNU/Hurd!
<gnu_srs> gg0: Sorry, fstabinfo and moutinfo are parts of openrc, my bad:-D
<gnu_srs> mountinfo*
IRC, freenode, #hurd, 2014-01-15
<gnu_srs> Hi, is these some simple way to find out the sequence of commands
executed during boot:
<gnu_srs> current using runsystem.gnu and with sysv-rc using runsystem.sysv
<gnu_srs> I need to edit on file of OpenRC before trying to boot with
it. (mainly mounting /run/*)
<gnu_srs> Is mount functional or is settrans .needed?
IRC, freenode, #hurd, 2014-01-16
<ArneBab> gnu_srs: you are adding OpenRC? cool!
<gnu_srs> ArneBab: Working on it, will try booting when my questions here
have been answered ;-)
<teythoon> gnu_srs: mount is functional enough to boot Debian/Hurd using
sysvinit
<teythoon> gnu_srs: you could add "set -x" to runsystem.*, or add "bash" to
just drop into a shell and examine the environment interactively
<gnu_srs> teythoon: Hi, is mount a wrapper on top of settrans ...?
<teythoon> yes
<gnu_srs> how to log the boot sequence, when booting the mach console is
cleared when the hurd console starts?
<teythoon> you could just disable the hurd console
<gnu_srs> and the kvm console does not have scrolling functionality
<teythoon> it's actually the mach console that lacks this
<gnu_srs> copying manually is cumbersome, even if all is readable
<teythoon> but as a workaround you can use kvm .... -curses and use xterms
backlog
<teythoon> and c&p works then :)
<gnu_srs> tks, I'll try with that:P
IRC, freenode, #hurd, 2014-01-17
<gnu_srs> BTW: zigo successfully booted openrc on Hurd, I haven't tried
yet,, you know things coming in between. He used my patches to create
updated ones:)
<gnu_srs> that version is now in experimental (I still have to operate away
all those PATH_MAX issues, and fins at least one sh file).
<teythoon> :/
IRC, freenode, #hurd, 2014-01-21
<gnu_srs> teythoon: I don't get a scrollable output when using -curses in
kvm, to be able to see all startup messages. Any other ideas?
<teythoon> gnu_srs: are you sure ? i just tested this, and it works nicely
for me
<teythoon> gnu_srs: that's how i created all the "screenshots" for my blog
posts
<gnu_srs> teythoon: kvm -m 1024 -net nic,model=rtl8139 -net
user,hostfwd=tcp::5564-:22 -curses -hda debian-hurd-20140115.img
<teythoon> ah, my bad
<teythoon> gnu_srs: try -nographic
<teythoon> oh, and maybe you need to add console=com0 to the gnumach
command line
<teythoon> b/c with -nographic, the first serial port is connected to qemus
stdio
<teythoon> sorry, i mixed this up
<gnu_srs> and how to add console=com0 to the qemu start oprtions? -kernel
and -append are Linux only
<teythoon> # grep console /etc/default/grub
<teythoon> GRUB_CMDLINE_GNUMACH="console=com0 --crash-debug"
<teythoon> and if you want grub on the serial port:
<teythoon> # grep serial /etc/default/grub
<teythoon> GRUB_TERMINAL=serial
<teythoon> GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8
--parity=no --stop=1"
<gnu_srs> teythoon: with -nographic I don't get any output at all?
<teythoon> did you run update-grub ?
<gnu_srs> aha, will do
<gnu_srs> still no scrollbar with gnome-terminal, will try with xterm and
rxvt
<gnu_srs> it works: with rxvt, tks:-D
<teythoon> good :)
<teythoon> i found -nographic to be quite handy
<gnu_srs> in /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet" and
GRUB_CMDLINE_LINUX="" #GRUB_DISABLE_LINUX_UUID=true
<gnu_srs> linux configuration parameters in a gnumach boot setup?
<teythoon> those won't be used
<teythoon> unless the grub scripts find a linux kernel in /boot
<teythoon> it's just the stock debian configuration file
<gnu_srs> nevertheless:-(
<teythoon> what ?
<gnu_srs> there could be OS-specific files: Linux, kFreeBSD, Hurd?
<teythoon> or, preferebly, one that works on every os ? like it is now ;)
<gnu_srs> OK, one that works on every OS, with a common part and
OS-specific parts?
<teythoon> that's how it is now
<teythoon> stuff with LINUX in it is used for linux
<teythoon> stuff with GNUMACH in it is used for gnumach
IRC, freenode, #hurd, 2014-01-22
<gnu_srs> teythoon: A boot message segfault: (syv-rc specific?)
<gnu_srs> + exec /sbin/init -a
<gnu_srs> INIT: version 2.88 booting
<gnu_srs> Using makefile-style concurrent boot in runlevel S.
<gnu_srs> end_request: I/O error, dev 02:00, sector 0
<gnu_srs> Segmentation fault
<gnu_srs> Activating swap...done.
<gnu_srs> Checking root file system...fsck from util-linux 2.20.1
<gnu_srs> another: mount: cannot remount /proc: Invalid argument
<gnu_srs> ...
<gnu_srs> df: Warning: cannot read table of mounted file systems: No such
file or directory
<gnu_srs> openrc boots on Hurd, login (user,root) works, read-only mode so
far, have to tweak some scripts:)
<braunr> not bad
<ArneBab> gnu_srs: woah!
<ArneBab> very cool!
IRC, freenode, #hurd, 2014-01-22
<ArneBab> I think with that you are doing the most useful thing to avoid
OpenRC: If it provides almost the same as systemd and runs on the Hurd,
then there is no technical reason for using systemd, but many against it.
<ArneBab> s/avoid OpenRC/avoid systemd/
<ArneBab> (gah, brain is jumbled)
<Shentino> I hate systemd because it monopolizes cgroups
<Shentino> which is SUPPOSED to be a generic interface open to anyone
<Shentino> I do not want an unholy alliance in a kernel-user api
<azeem_> ArneBab: the openrc maintainer will take care it will get
communicated
<azeem_> ArneBab: also, not sure what you mean about systemd, the question
isn't so much between openrc vs. systemd, but upstart vs. systemd
<azeem_> at least for the Technical Committee decision, none of the
tech-ctte members seems to consider openrc as n realistic contender
<azeem_> s/as n/as a/
<gnu_srs> azeem_: seem like it is so:-(
<gnu_srs> maybe in a future, if openrc gets some attention and developers,
it could become a one-for-all solution;-)
<teythoon> gnu_srs: nice :)
<teythoon> ignore the proc related message
<teythoon> gnu_srs: there is no way to associate the segfault with a
process for me, can you shed some light on which process dies ?
<teythoon> as for df complaining, you could fix this up like youpi did:
<teythoon> grep ln /etc/hurd/rc
<teythoon> ln -s /proc/mounts /var/run/mtab
<teythoon> the proper way is to fix our libc of course
<gnu_srs> teythoon: I was just coping the boot messages, I don't know
either which process segfaults
<teythoon> hm, maybe you can make openrc more verbose about what it starts
<gnu_srs> All I wrote earlier was from sysv-rc
<teythoon> ah
<teythoon> i've never seen that then
<ArneBab> azeem_: actually I think OpenRC is the only sane choice: It is
the only choice which supports other kernels.
<ArneBab> Shentino: I can’t stand systemd, because it establishes a tight
control over the init process by encouraging developers to add
dependencies to libraries which are so tightly coupled with others, that
they cannot be adapted without affecting the whole system.
<ArneBab> Shentino: But I wrote about that in much more details:
http://draketo.de/light/english/top-5-systemd-troubles TL;DR:
distributions become completely dependent on a small group and they throw
away the skills their maintainers already have (shell scripting)
<ArneBab> And systemd is Linux-only…
<ArneBab> …with no intention of changing that.
<braunr> why would debian strive to support other kernels ?
<braunr> instead of other kernels adjusting ?
<braunr> if posix introduces new apis, are we going to say no, or are we
going to try and support them ?
<braunr> the issue of multi-kernel support is completely irrelevant
<braunr> what you're saying about tight coupling is actually the only real
issue of systemd
<ArneBab> braunr: I see a difference between providing a stable API which
others can easily replicate and a running target with no intention to
become cross-kernel usable (my experience with udev suggests that they
won’t really try to keep anything stable for long).
<ArneBab> braunr: but the tight coupling is the main issue for me, too:
that creates a vulnerability for the free software community.
<braunr> no, the free software community doesn't risk much here
<braunr> it's a technical problem
<braunr> ok, yes, posix as a point of convergence is clearly not the same
as linux as an implementation that diverges
<braunr> agreed
<ArneBab> if the systemd people decide to go a certain direction which
makes it impossible to provide a certain feature while using their new
tech, then there is a problem.
<braunr> but it still implies we have to adapt
<braunr> from my point of view, multi-kernel distributions are a technical
heresy
<braunr> if you want something really efficient, you want it very well
integrated
<teythoon> i'm concerned by the linux kernel making up interfaces w/o
proper considerations
<ArneBab> braunr: in Gentoo we had all the hassle with /usr on a separate
partition. There are usecases for that, and Gentoo wanted to provide
them, but udev (now systemd) made that impossible.
<braunr> teythoon: yes i'm concerned about that too
<teythoon> we will never be able to implement the cgroup interface for
example b/c it is too badly designed
<braunr> badly ?
<braunr> it's system specific
<ArneBab> braunr: also the systemd folks could essentially hold Linus at
ransom: “We couple userspace tightly to implementation details in the
kernel, so when you break the implementation in a way which we don’t
like, you’ll break userspace in the worst possible way”
<braunr> it's very hard to design an interface without properly
understanding what it would internally imply in the implementation
<braunr> ArneBab: that's already the case
<teythoon> system specific in a way that it will be impossible to implement
on non-monolithic kernels
<braunr> teythoon: exactly
<braunr> they didn't think of that because they don't care
<braunr> and why would they ?
<braunr> it doesn't make the interface bad per se
<ArneBab> it is the case in systemd, but not in sysVinit
<braunr> well it is too
<braunr> but sysvint is less demanding
<braunr> again, the coupling is the problem
<ArneBab> yes
<braunr> systemd comes from people with other goals and interests
<ArneBab> I think everything I wrote comes down to that.
<braunr> they're very technical, very business oriented
<braunr> they want to get up to speed with competitors quickly
<braunr> they're not wrong in doing that
<braunr> it just helps understand why they get with such results
<ArneBab> A distribution would be foolish to let other people take over a
crucial part of the system when those other people have a track record of
coupling more and more parts of the system with their product.
<braunr> and i agree, i don't want it either
<braunr> but please, stop with the nonsense
<braunr> don't say openrc is the only sane one because it's the only
multikernel one
<braunr> personally, i consider that very argument almost insane itself
<braunr> considering distributions that are hardly used can really have any
weight in the decision is absurd
<ArneBab> openrc is the only sane one, because it keeps already aquired
skills useful.
<braunr> s/distributions/kernels/
<ArneBab> (that’s my opinion)
<braunr> we have to make progress
<braunr> the init system is clearly obsolete and lacking features
<braunr> so "acquired" skills here are irrelevant too
<braunr> if it takes acquiring new skills to operate a better init system,
i'm all for it
<braunr> after all, it makes a lot more sense to me than all those fancy
languages/technologies like C# and ruby that have gained so much
popularity in so little time
<ArneBab> If you can get a similarly good init system wiothut forcing
people to learn new skills, that’s a big win.
<braunr> you probably can't
<ArneBab> OpenRC is pretty close in features to systemd
<teythoon> err
<teythoon> not even close
<braunr> teythoon is right
<braunr> openrc is just sysvinit++
<teythoon> no
<teythoon> openrc replaces the sysv rc, not sysvinit
<braunr> ok
<teythoon> it complements it
<braunr> i wasn"'t being pedantic here
<teythoon> nicely in my opinion
<braunr> yes i like it too
<braunr> but i'm afraid it's not a complete solution
<ArneBab> I think I need to be more pedantic in what I say: A system-boot
with OpenRC is pretty close in features to a system-boot using systemd.
<braunr> on the other hand, when i see discussions about event driven
systems and handling of dependencies, it sounds like something like
openrc could do the job, and something else, system-specific, would
handle the rest
<braunr> ArneBab: i disagree
<teythoon> me too
<teythoon> ArneBab: have you actually used systemd?
<ArneBab> I have read about what it provides.
<ArneBab> My udev experience burned me pretty badly.
<braunr> udev is only one part
<braunr> but actually, coupling is both a problem and a great feature
<teythoon> yes
<braunr> it's precisely the integration of many services previously
organized in a very messy way that makes it better
<braunr> and cgroups, by accurately tracking resources, allow even better
control
<teythoon> heh, i watched lennarts recent talk about kdbus
<ArneBab> but it does so by pulling in more and more parts instead of
providing a clean interface which separate projects can use.
<braunr> again, the coupling is too tight
<braunr> it's hard to hook in between
<ArneBab> teythoon: I watched lennart troll a talk pretty badly…
<ArneBab> braunr: yes
<teythoon> he cites mach and hurd for having an nice ipc mechanism, and
linux lacking such a system
<braunr> haha
<braunr> i was expecting such comparisons :)
<ArneBab> that’s why he writes an init-system which does not run on the
Hurd…
<teythoon> ArneBab: that's trolling on your part ;)
<braunr> :)
<ArneBab> somehow yes…
<braunr> what i personally get out of this is that, in the end, proper
messaging at the kernel level is something people do want
<braunr> and if you make stuff like x use it, why not things like the
network stack and the file system
<teythoon> i wish the linux kernel would allow the kernel devs to write
nicer interfaces
<ArneBab> yes
<braunr> they're almost in the process of acknowledging the merits of
multiserver architectures :)
<teythoon> b/c they lack a proper ipc mechanism, they do stuff like ad-hoc
filesystem-based interfaces that are crappy to support on the hurd :-/
* ArneBab has been out of the loop for too long…
<braunr> teythoon: what file system do you consider "crappy to support on
the hurd" ?
<teythoon> braunr: cgroupfs in particular
<teythoon> not crappy, but impossible
<braunr> well, that's probably because we need realy resource containers
first
<braunr> real*
<teythoon> no, we'll never be able to implement the current interface
<braunr> i didn't study it as you did so i trust you
<teythoon> braunr:
http://teythoon.cryptobitch.de/posts/cgroupfs-is-as-cgroupy-as-it-gets/
<braunr> ok this would require proper support at the client side
<teythoon> yes
<braunr> i wouldn't say impossible but definitely not as clean as we would
want it
<braunr> far from it
<teythoon> how would you ever implement it w/o fixing the client
(i.e. fixing the interface first) ?
<braunr> the client would translate the request
<teythoon> magical write retries ?
<braunr> probably
<teythoon> uh
<braunr> clients are the only entities which know what their file
desctiptors refer to
<braunr> descriptors*
<teythoon> yes
<braunr> so writing such a request would make the client get a magic retry,
and use the proper rpc, passing the proper rights instead
<teythoon> yeah, i can see how that could work
<teythoon> but i'm not sure that we should go down this path ...
<braunr> we probably really do'nt want to :)
<braunr> i'd personally be fine if debian would allow two init systems
<teythoon> me too
<braunr> with the powerful linux-specific one still allowing sysvinit
scripts
<teythoon> in particular b/c the sysvinit scripts are already there
<braunr> from what i've read, they all provide some decent backward
compatibility with sysvinit
<teythoon> yes
<braunr> and i think we can count on the linux community to riot if,
assuming systemd was chosen, it becomes too hard to use and tweak
<braunr> again, these people want their software to be used
<braunr> so they'll probably manage something decent in the long run,
whatever is chosen
<braunr> i don't care much
<braunr> :)
<kilobug> AFAIK Debian is planning to let users chose the init system, the
discussion is only on what should be the main/default one; but I might
have misunderstood it
<braunr> that was one of the possibilities, yes
<braunr> maybe we could help the debate by agreeing on whether or not we
consider supporting ports is that important, as port maintainers,
considering we'll probably keep the ability to use sysvinit scripts
anyway
<braunr> and making that decision known
<teythoon> and stating that we consider openrc an worthwile incremental
improvement, whatever debian decides to do wrt to the default init system
<braunr> for example, yes
<braunr> we should discuss that with youpi and thomas
<braunr> tschwinge: ^
<braunr> when they have some time later :)
IRC, freenode, #hurd, 2014-01-24
<gnu_srs> Good news, a successful boot of Hurd with OpenRC:
http://paste.debian.net/78119/ :-)
<gnu_srs> ramains to fix the false negative for checkpath -W
<gnu_srs> remains*
<braunr> not bad
<gnu_srs> teythoon: btw, the segfault happens when starting the bootlogd
service:
<gnu_srs> end_request: I/O error, dev 02:00, sector 0
<gnu_srs> Segmentation fault
<teythoon> gnu_srs: nice progress :)
<teythoon> i've never seen bootlogd crash like that, though i
<teythoon> i'm not sure it is installed
<gnu_srs> how can I check / ? it is mounted RW and even if cd to /run which
is on tmpfs, fsysopts --readonly fails:
<gnu_srs> :fsysopts: /: --readonly: Device or resource busy
<gnu_srs> I don't have bootlogd installed the segfault is at:
<gnu_srs> checkroot.sh: hwclock.sh mountdevsubfs.sh hostname.sh hdparm
keyboard-setup
<gnu_srs> called by /etc/rcS.d/S06checkroot.sh
<teythoon> you should probably create this directory that it fails to
create early in the boot process
IRC, freenode, #hurd, 2014-01-25
<antrik> braunr: being Linux-only is *part* of the "tight coupling"
strategy of the systemd cabal
<antrik> of course you could implement all the Linux-specific interfaces on
other systems; as you could implement any other interfaces relied upon or
provided by systemd components...
<antrik> (this is in fact Lennart's favourit cop-out argument whenever
someone raises concern about this)
<antrik> the problem however is that such alternative implementations
usually have prohibitive costs
<braunr> yes i know
<antrik> (and Lennart knows that perfectly well... he doesn't exactly take
pains to conceal the fact that it's a cop-out)
<antrik> their whole point is to create a tightly integrated stack of
monopolistic components, giving a shit about any possible alternatives
<antrik> this does have an obvious appeal: it *significantly* reduces the
cost of innovation within their stack
<antrik> at the same time however it kills the traditional innovation
driver in the free software eco-system, which is competition among
interchangable components
<antrik> quite frankly, it makes little sense that other distributions are
embracing systemd in droves: the tight coupling pretty much turns them
all into Fedora look-alikes, questioning the point of their very
existence...
<zacts> what is dmd?
<antrik> as for Debian considering fringe kernels in their decision, I
think it makes *perfect* sense: the real value of Debian is precisely the
fact that it supports so many different things, making it a good base to
build upon
<antrik> (it's just unfortunate that many Debian developers do not realise
this, and instead try to compete with user-oriented distributions...)
<antrik> zacts: daemon managing daemon? yet another new init system...
<zacts> yeah
<zacts> didn't know if you have an opinion on it vs systemd
<zacts> and whether or not hurd will use it..
<antrik> hm... not sure whether I do ;-)
<braunr> antrik: one could argue an init system is hard to make
interchangeable without also making it quite poor in functionality
<antrik> the GNU system uses it, right? when using the GNU system with the
Hurd (as it's really meant to be), that would obviously mean using DMD
with Hurd. though I'm not sure whether anyone has actually tried that
combination ;-)
<braunr> just to make it clear, i'm totally not in favor of systemd
<braunr> i'm just trying to measure the value of an interchangeable init
system here
<braunr> value versus cost
<braunr> why is it bad to try to compete with user oriented distros ?
<antrik> braunr: I suspect most of the really good things about systemd
could be kept while making it somewhat more open at fairly little cost...
<antrik> braunr: because that's not Debian's strength -- and never will be
<antrik> trying to compete in this space too hard is bound to fail, at only
bears the risk of loosing the actual strengths
<braunr> antrik: sounds true
<antrik> hm... thinking about it, I'd say it actually makes more sense for
the init system to be distribution-specific than kernel-specific...
<braunr> that makes sense
<braunr> but systemd isn't just an init system
<antrik> it's really the distribution's job to create a well-integrated
system. and basically, that's what the systemd cabal is doing for
Fedora...
<antrik> it's just problematic that they have so much influence in
important upstream projects, that they are basically killing any chance
for others to integrate things in different ways
<braunr> antrik: agreed
<braunr> the tight coupling i refer to is about the init system and the
upstream projects you mention such as udev, acpid, console-kit, etc..
<antrik> yeah... and GNOME
<braunr> is it really that coupled now ?
<antrik> don't really know; but judging from remarks people make, it must
be pretty bad
<braunr> this reminds me of the talk on gnome 3 last year at fosdem
<braunr> it would have been hilarious if gnome wasn't such an important
project
<antrik> (specifically, GNOME is now pretty much tied to logind AIUI, which
is not entirely inseparable from systemd -- but again, the cost is
prohibitive...)
<teythoon> i don't get what all the hate here is about ...
<antrik> in fact, certain people used that as an argument why Debian must
switch to systemd as init, as they are already pretty much forced to use
various of the other coupled components anyways, and trying to decouple
them is too costly for Debian...
<braunr> teythoon: hate ? here ?
<teythoon> i mean they don't do this for fun, they actually provide
something of value, right ?
<braunr> some value
<antrik> teythoon: they?
<braunr> but they remove the kind of value that made free software evolve
the way it did, as antrik said
<teythoon> the evil cabal around systemd ;)
<antrik> I didn't say "evil"... not explicitly at least ;-)
<teythoon> then again, if you are runnign linux/gnome3 and plug in a second
monitor, that one is automatically activated
<braunr> yes, that's what they want to achieve
<teythoon> that's what they achieved
<braunr> i mean, they targetted that, it's not a side effect
<teythoon> and anyone not happy with how they did that can surely provide a
nicer solution ;)
<antrik> teythoon: as I said, there are clearly good aspects to what they
are doing -- but at the same time it's very dangerous to the free
software eco-system...
<braunr> teythoon: not easily
<teythoon> antrik: i don't buy that
<braunr> i do
<teythoon> braunr: yes, not easily. that is kind of the point, right ?
<braunr> pulling projects such as gnome into a category of kernel specific
applications is dangerous
<braunr> teythoon: well, considering who they are and the means they have,
they could have spent the time to do it right for everyone
<teythoon> maybe
<antrik> err... activating a second monitor is not in any way tied to
systemd or related compontents... I think you are talking about a second
seat
<teythoon> that's another killer feature they achieved, yes
<antrik> (which is nice, but quite frankly, a niche use case in my book...)
<teythoon> maybe you're not the typical user
<antrik> I'm not. but the *typical* user definitely doesn't care about
multi-seat
<teythoon> if you say so
<teythoon> antrik: when you say it's dangerous what 'they' are doing, what
do you mean exactly ?
<teythoon> dangerous for whom ?
<antrik> asides from schools in developing countries, who try everything to
save on IT costs, I really can't think of many users for multi-seat...
<teythoon> (maybe schools all around the world trying to cut down their
costs?)
<teythoon> or like everyone, here, a $30 dongle that gives you an extra
workstation, how awesome is that ?
<antrik> teythoon: see above: they are killing the ability to combine
interchangable components, which has always been a core asset of the free
software ecosystem
<teythoon> antrik: so gnome is going for systemd, and gnome loses the
ability to be used w/o systemd
<teythoon> why do you care ? how does this affect the whole ecosystem ?
<teythoon> i really don't get why everyone is getting so upset about this
<antrik> teythoon: who cares about a dongle giving an extra workstation?
the remaining users of workstations are either corporate -- who prefer
dedicated boxes for organisational reasons -- or gamers, who want all the
power to themselves...
<braunr> teythoon: well gnome is kind of one of the major destkop software
in the free software world
<antrik> s/one of//
<teythoon> antrik: you stated that you havent used gnome3, yet you have an
opinion how tightly it should be coupled with systemd or linux
<teythoon> people who haven't used systemd or upstart have an opinion about
which one should be preferred
<braunr> teythoon: why do you think people shouldn't think about systems as
a whole ?
<antrik> teythoon: actually, I am using it (for some value of "use") --
though in legacy mode, as my hardware can't run the new bling...
<braunr> in that case, people shouldn't be allowed to vote, because that
would require them to be politicians ..
<teythoon> it's okay to think about that
<braunr> i don't think it is
<antrik> teythoon: but seriously, whether *I* have used it is quite beside
the point. I have no illusions about being a niche user
<braunr> people don't need to use something to actually understand it
<teythoon> but i cannot stand all the whining lately in the free software
world...
<braunr> whining isn't fair
<braunr> i mean, the word
<teythoon> y ?
<braunr> it's a big problem and complaining to force a debate is important
<teythoon> yes, but "they" are solving problems, and everyone is
complaining for one reason or the other
<braunr> they are also creating problems
<braunr> and not everyone is complaining
<teythoon> as opposed to offering alternatives
<braunr> that's a major issue, a lot of people are favorable to these
changes
<teythoon> and if you don't like what "they" are building, you are free not
to use it, no ? that's a freedom too ;)
<braunr> no
<braunr> you aren't
<teythoon> what ?
<braunr> that's precisely the point
<braunr> you'll be de facto forced to use it if you want to keep using the
rest
<teythoon> i'm free not to use gnome3
<braunr> you won't be free from using linux if you want gnome3
<teythoon> what kind of argument is that ?
<braunr> i'm abusing the word freedom
<braunr> because it has no clear meaning in practice
<braunr> as antrik said, it's about interchangeability and portability
<braunr> and alternatives
<braunr> accepting the way systemd is designed is a major shift towards
making linux its own standard, away from the rest
<braunr> and the way it's done isn't thought to easily allow the
alternatives to keep up with the changes
<teythoon> we agreed the other day that they shouldn't create ad-hoc
interfaces like they do, yes
<braunr> well that's the whole point
<teythoon> you just talked "about the way systemd is designed"
<braunr> they could invest some more effort to make well designed
interfaces that allow changing both the dependencies and the services
provided
<teythoon> how is that related to bad interface design ?
<braunr> for me, it's almost a synonym
<braunr> and we discussed it
<teythoon> aren't tightness of coupling and quality of interfaces
completely orthogonal ?
<braunr> it is designed with a narrow set of apparently company directed
interested towards a single system, a single distribution even, and
nothing else
<braunr> no
<braunr> absolutely not, when it's about something that should be
interchangeable
<braunr> an interface that forces tight coupling is of low quality to me
<antrik> braunr: they claim it's not actually company-directed... and I
tend to believe them on *that* point TBH
<braunr> antrik: this would have been a valid reason at least
<antrik> teythoon: it's just not right that some people can no longer use
major pieces of free software just because a tiny but highly vocal cabal
decides to disrupt the whole ecosystem
<teythoon> what are you talking about ? you are free to use older versions
of the software
<braunr> i's not technically feasible
<braunr> or it would require forking to maintain
<braunr> again, it's the start of a rift
<teythoon> but, if the gnome people want to go into that direction, who are
you to say that they shouldn't ?? that's what i get the least about this
kind of argument...
<braunr> i'm part of the free software community
<braunr> more accurately, the free unix-like community
<teythoon> and you are actively developing gnome... ?
<braunr> if they want to get out of this community, they'll hurt it, and
themselves
<braunr> do you understand what a rift is ?
<teythoon> but that's their choice, no ?
<braunr> a major division ?
<braunr> so what ?
<braunr> it doesn't mean it's a good one
<teythoon> you pick the desktop environment you like next best and be done
with it ?
<braunr> it's almost public service at this point
<braunr> what if they all do the same thing ?
<teythoon> err
<teythoon> they don't
<braunr> you won't be free to do what you want because the technical
possibility will have disappeared
<braunr> kde might
<braunr> if only to compete with gnome
<teythoon> well, if you don't like hte direction a project is taking, you
fork it
<teythoon> that's what happened
<braunr> exactly ..
<teythoon> why the long faces ?
<braunr> forks increase complexity and reduce manpower
<braunr> fork == division
<braunr> forking in the free software community is normally a last resort
<teythoon> huh ? since when is this considered a bad thing ?
<braunr> it's not a bad thing per se
<braunr> it usually implies a bad situation
<teythoon> < braunr> fork == division
<teythoon> and division == rift
<braunr> think of these situations that were caused by stupid drama and
lead to the duplication of a lot of effort
<braunr> openbsd, eglibc, jenkins, to name a few
<teythoon> i don't
<teythoon> why would i ? i never created these forks
<braunr> it affects the community as a whole
<teythoon> but the people who did thought it was necessary
<braunr> the fact they could do it is good, the fact they had to do it
isn't
<braunr> they were usually forced by the situation
<braunr> and often by the stupidity of other people
<teythoon> someone forced someone else to fork a project ? with a gun or
something like this ?
<teythoon> i don't buy this ;)
<braunr> of course not ..
<braunr> eglibc was forced by the inability of drepper to accept a whole
class of patches
<braunr> openbsd because theo de raadt has some huge ego
<braunr> for jenkins, it was a licensing issue iirc
<braunr> nothing technical at all
<braunr> nothing in the interest of the community
<teythoon> err
<teythoon> it brings diversity
<braunr> no
<braunr> netbsd versus freebsd brings diversity
<teythoon> i thought that was a good thing
<braunr> openbsd was just agotistic crap
<braunr> ego*
<teythoon> if there is no diversity, why should stuff be interchangeable if
there are no alternatives?
<braunr> and netbsd and freebsd aren't exactly forks, they're both bsd
based but had different goals from the start
<braunr> that's not what i'm talking about
<braunr> eglibc isn't exactly a new libc
<braunr> it's glibc+the stuff that should have gone into it
<antrik> teythoon: the stuff the systemd cabal does builds on the work of
thousands of projects and people; yet they act as if the don't own anyone
anything, and it's fine to boot out large parts of the community whos
work they are building on
<braunr> iceweasel isn't a whole new firefox
<braunr> most often, alternatives aren't forks of one another
<braunr> if they are, they have diverged a lot
<teythoon> antrik: that is your interpretation, and i respectfully disagree
with it;)
<braunr> and usually have different goals
<braunr> that's diversity, and i'm very ok with it
<braunr> (being a hurd guy and all)
<braunr> but forking because of decisions that prevent alternatives is a
very bad reason to fork
<teythoon> again, who are you to tell a project (say gnome) what they
should do or not ?
<braunr> that question makes no sense
<braunr> we're trying to think objectively
<braunr> forget who we are
<braunr> think about what should be done
<teythoon> no such thing ;)
<braunr> ok well, in that case, i'm a very smart person who knows a lot of
things, and people had better do what i tell them ;p
<braunr> satisfied ? :)
<teythoon> yes
<teythoon> that's much better actually
<braunr> not really ..
<teythoon> it's more honest
<braunr> no it was sarcasm
<braunr> what was honest are the arguments i explained
<braunr> why care about who says them ?
<teythoon> i do
<antrik> teythoon: there is not much interpretation in there really. some
of their own statements are quite explicit...
<braunr> damn non scalable kernel ..
<teythoon> who is "their"? what statements ?
<braunr> teythoon: when building glibc, there are so many nodes to fake
that ext2fs+fakeroot allocate enough ports to starve kernel memory ...
<teythoon> if i were mr. gnome3 and you would tell me that i should cuddle
with systemd b/c that's bad for one reason or another, the first thing
i'd like to know is who is telling me that
<braunr> teythoon: why not solely consider the argument ?
<teythoon> braunr: yes, i can imagine fakeroot doing that
<antrik> teythoon: Lennart and his friends. not sure how much of these
statements I have seen written down -- part of it I heard myself from
their own mouths
<teythoon> braunr: b/c maybe i like to develop my project in the direction
i want
<braunr> that's unrelated
<teythoon> and if anyone disagrees, she may fork
<braunr> this is a debate
<teythoon> why ?
<teythoon> so now we are debating what i may develop or not ? you lost me
;)
<braunr> a way to reach consensus
<braunr> many people are discussing so that projects like debian and gnome3
make the best decisions
<braunr> a naive way to explain it is that the result is the sum of what
everyone likes and how louds he speaks for it
<teythoon> sure but you are not a gnome developer, no ?
<braunr> no, but again, i'm a free software community member
<braunr> and this affects the whole community
<braunr> because gnome3 is a major software component used by a lot of
people
<braunr> well, gnome at least
<teythoon> so the gnome project needs to seek consensus with everyone of
the free software community ?
<braunr> no
<braunr> that would be unanimity
<teythoon> but wrt to the systemd integration ?
<braunr> siding with systemd is starting to get away from the free software
community
<braunr> or, by bringing a lot of people along, dividing it
<teythoon> that's your interpretation
<braunr> yes
<braunr> always
<braunr> you don't have to say it, we're not doing raw science here
<braunr> it's implicit
<teythoon> i think it's important to point that out and make it explicit
<braunr> you made it several times
<braunr> we got the point
<braunr> what matters in the current discussion is whether you agree or not
and why
<braunr> and this will be your interpretation too
<braunr> and we'll see if it's convincing
<braunr> but, from experience, i expect noone will be convinced ;p
<teythoon> ^^
<braunr> the issue is too tied with the core goals we have in mind
<teythoon> but why does it matter whether i agree or not
<teythoon> that's my point actually
<braunr> you seem to have a problem understanding the issue, i was trying
to convince you there is one
<braunr> so, if i want to achieve that, it matters
<teythoon> what core goals ?
<braunr> basic dialectic
<braunr> well, for example, for me, i want people to think of the system as
a whole
<braunr> i want something effective, technically very good, and that
respects user freedoms
<braunr> i also want alternatives, i won't explain why, let's say it's
obvious
<teythoon> i agree
<braunr> well, systemd people don't think of the system as a whole
<braunr> here, what i call "system" is very large
<braunr> it would almost equal society
<braunr> i understand why they do that
<braunr> they have the right to do that
<braunr> but then i could say i understand why people make proprietary
software, and they also have the right to do it, i still won't approve it
<braunr> it contradicts my personal goals, my personal view of how things
should be
<teythoon> i completely agree
<teythoon> but then again, what you said now and the way you said it was
very different
<braunr> maybe, it's 3am, i'm sick and exhausted :)
<teythoon> more abstract
<braunr> when i give an opinion
<braunr> actually, when anyone gives an opinion
<braunr> i consider it implicit that it's their point of view alone
<braunr> they're not enforcing anything
<braunr> merely speaking out
<teythoon> people tend to overestimate the importance of their own opinion
<braunr> hm i wouldn't say so
<braunr> and that's probably why the "who" doesn't matter a lot to me
<braunr> it would matter if the person in question had real power
<braunr> and his opinion could have a strong influence
<braunr> in which case it wouldn't be overestimated
<braunr> i could say what i think to systemd people
<antrik> teythoon: quite frankly, I'm not sure what you are complaining
about. the systemd followers are trying to impose their opinions on
various projects. other people (including braunr and me, among many
others) are voicing counter-opinions. what's wrong with that?
<braunr> but i'm pertty certain the weight they'll associate to what i tell
them will be very low :)
<braunr> antrik: he called it "annoying whining"
<braunr> i think it's the only problem
<antrik> braunr: I don't think the systemd people associate much weight to
*anything* others say... ;-)
<braunr> heh :)
<braunr> to make an historic analogy
<braunr> it seems to me they're repeating the same mistakes others did
during the unix wars
<teythoon> antrik: but when you say "the systemd followers are trying to
impose their opinion on various projects", don't you dismiss the
possibility that the gnome3 people just want to make external displays
hot-pluggable?
<braunr> of course they do
<braunr> don't you dismiss that proprietary software author just want to
make money ?
<teythoon> no
<braunr> well, if that's the only thing you keep in mind to make your
opinion, you'll miss important points
<teythoon> that is an example of course
<braunr> they're sacrificing interchangeability and starting a possibly
major rift in the community for hot pluggable displays
<braunr> it may not be worth it
<teythoon> not supporting stuff like that might make the whole ecosystem
obsolete
<braunr> i'm not saying it shouldn't be done
<braunr> i'm saying it should be done while sacrificing other important
things
<braunr> it would just take a little mort effort
<braunr> and even if it wasn't done
<teythoon> that's what i meant by "whining"
<teythoon> no offense
<braunr> what is the problem of it being "obsolete" ?
<teythoon> but talk is cheap, offering alternative solutions is hard
<braunr> isn't unix obsolete ? isn't xorg obsolete ?
<braunr> hum no
<teythoon> no one did, so they implemented their nice features
<braunr> the point isn't to offer alternative solutions
<braunr> it's to make them possible
<braunr> or at least, not deny their technical feasibility because they
don't care
<braunr> teythoon: see, "interchangeability and starting a possibly major
rift" don't look to conflict with your personal goals
<braunr> that's the point where i think i can no longer do anything to
convince you
<braunr> so i'll head to bed :)
<teythoon> heh, me too :)
<braunr> honestly, i don't care a lot
<braunr> i mean
<braunr> it won't change much for me
<braunr> but again, my brain is wired to think of things as a whole
<braunr> on that note, good night :)
<teythoon> good night :)
<antrik> teythoon: again, IT'S NOT ABOUT DISPLAYS
<antrik> believe me, I do have some understanding how display hotplugging
works
<antrik> also, the problem is not that gnome3 supports logind. the problem
is that gnome3 works *only* with logind now AIUI
<antrik> there is yet another way to state the fundamental problem
<antrik> there is a kind of social contract among free software projects:
every maintainer takes a reasonable amount of extra effort to support use
cases beyond his own. in return, his use cases are supported by other
maintainers
<antrik> the systemd guys are breaking this contract, by explicitly
refusing, up front, to take *any* effort to accomodate other projects'
needs
IRC, freenode, #hurd, 2014-01-28
<azeem_> teythoon:
https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/EgKwQV8te7s
<teythoon> azeem_: pffff :)
<braunr> heh
<teythoon> which reminds me
<teythoon> if we want to state our position wrt the default init system
debate we should probably do it right now
<braunr> yes
<teythoon> ml or collaborative editor ?
<azeem_> well, tech-ctte chair called the vote only for the default init
system for the Linux-ports
<azeem_> the vote got shot down on technicalities, but that might stand
<azeem_> I think that is a good thing, cause it implies that not one init
system has to be adopted across all ports
<teythoon> we talked the other day that it might make sense just to state
our view and our needs
<azeem_> sure.
<azeem_> I think what's needed is (i) an init-system agnostic system to set
the enable/disable state of services (ii) possibly mandating a .ini-style
config file along the style of whatever init system gets chosen as
default for Linux, to be used by non-Linux init systems as inut
<azeem_> input*
<azeem_> just my 0.02 EUR
<teythoon> uh
<braunr> looks overkill
<teythoon> i was thinking more along the lines of 1) we have never used the
default debian init system and are cool with not using the default in the
future, 2) we intend to use sysvinit in the future, 3) to that end, we
ask the init script machinery to be left in place
<braunr> but then, people managed to write stuff like libvirt
<braunr> so who knows
<teythoon> 4) we will help maintaining it as part of our porter effort
<braunr> i agree with teythoon
<teythoon> 5) we look forward to using openrc as incremental improvement,
complementing our sysvinit boot solution
<braunr> yes that would be nice
<teythoon> i'll write a draft to debian-hurd, ok ?
<gnu_srs> openrc now has a dependency loop resolver, so parallel would
work:)
<teythoon> so is insserv, isn't it ?
<gnu_srs> there were complaints on openrc
https://bugs.gentoo.org/show_bug.cgi?id=391945 in the tech-ctte
discussions, now fixed
<azeem_> gnu_srs: please accept the fact that openrc will not be picked by
the tech-ctte for the Linux ports
<gnu_srs> azeem_: I do, I'm referring to arguments during the discussion
(history)
<azeem_> sure, just checking
<ArneBab> teythoon: your post is being used to portray systemd cgroups
treatment as the right way…
<teythoon> ArneBab: so ?
<braunr> it probably is the right way
<braunr> that's not the problem
<ArneBab> do you want to clear that up? (do I remember correctly that you
did not like that way?)
<braunr> we don't like the cgroups interface
<teythoon> i will
<braunr> not the feature
<ArneBab> braunr: that’s what I meant
<teythoon> exactly
<braunr> the feature amounts to resource containers in the hurd critique
...
<braunr> we do want that too :)
<braunr> anatoly: you want them to rewrite cgroups ?
<braunr> err
<braunr> ArneBab: ^
<teythoon> i've been thinking
<teythoon> maybe the magic write stuff isn't that bad after all
<braunr> :)
<braunr> i was thinking the same thing actually
<teythoon> i mean, it's not the nicest thing, but it shows how flexible our
solution is
<braunr> the hurd is a lot about glue code already so why not
<teythoon> the problem is that there is no way to test cgroupfs
<teythoon> the main user is systemd, and it requires tons of other stuff
<braunr> right
<teythoon> any other user of cgroups is also probably using other
linux-interfaces too
IRC, freenode, #hurd, 2014-01-29
<gnu_srs> About openrc having a dependency loop resolver: <teythoon>: so is
insserv, isn't it ?
<gnu_srs> I found is_loop_detected() in insserv/listing.c but that one just
exits without telling where the loop is
IRC, OFTC, #debian-hurd, 2014-01-29
* youpi trying the new sysvinit
<youpi> hopefully we'll then be able to at last use the proper ifup/ifdown
debian way for networking :)
<youpi> teythoon: why leaving hurd's runsystem by default rather than
sysvinit's?
<youpi> ah, another issue, too, now that /dev/vcs appears in /proc/mounts,
umountfs would umount it
<youpi> ideally umountfs would not umount passive translators
<youpi> we could blacklist /dev/vcs in umountfs, but the same issue would
happen for user-defined translators in their own home, for instance
IRC, freenode, #hurd, 2014-01-30
<gnu_srs> booting with the new sysvinit and openrc versions: works:), but
only in recovery mode:-( Hangs before INIT: version 2.88 booting
<gnu_srs> after start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1]
exec init proc authtask c1120dc8 deallocating an invalid port 134517370,
most probably a bug.
<gnu_srs> related or an openrc problem? will test with sysv-rc
<youpi> I don't have such issue with sysv-rc
<gnu_srs> k!
<gnu_srs> shouldn't recovery mode mean starting in runlevel 1, I get
runlevel 2?
<youpi> it should
<pere> gnu_srs: recovery mode normally mean single user, which is between
rcS and rc2
<gnu_srs> I get INIT: Entering runlevel: 2
<pere> rcS.d should really have been named rcboot.d, as that is really what
it is.
<youpi> ah, right, recovery is not single
<youpi> (single as in init 1)
<pere> runlevel 1 is not single user either. it is more a gateway into
single user. see /etc/init.d/single to see what happen at the end of
runlevel 1.
<gnu_srs> init 1 and init 2 seems to work
<gnu_srs> well, the openrc dependency loop detector has found an init
script loop, maybe it has to be fixed?
<gnu_srs> disabling the hurd console solved the dependency loop problems,
thanks openrc;-)
<gnu_srs> (have to dig deeper to see where the loop is, and how to solve
it)
IRC, freenode, #hurd, 2014-01-31
<gnu_srs> Hi, does the hurd console work with sysv-rc: In operc I get with
#console -d vga -d pc_mouse --repeat=mouse -d pc_kbd --repeat=kbd -d
generic_speaker -c /dev/vcs
<gnu_srs> console: Console library initialization failed: Not a directory
<teythoon> gnu_srs: yes, it works with sysvrc
<teythoon> gnu_srs: check that /dev/vcs has the appropriate translator
record
<gnu_srs> showtrans /dev/vcs: empty on another box: /hurd/console
<teythoon> yes, fix that and your console will be fine
<gnu_srs> settrans /dev/vcs /hurd/console?
<gnu_srs> or should it be active?
<teythoon> no, set an passive translator record so that this will be
persistent
<gnu_srs> something is wrong: when starting the hurd console screen is
blanked (and hangs)
<gnu_srs> can I get the hurd console when running with the serial console
(to see boot messages)?
<teythoon> gnu_srs: yes, yuo can
<gnu_srs> will try that image then, tks:)
<gnu_srs> teythoon: how to create all underlying directories? ls /dev/vcs:
1 2 3 4 5 6
<teythoon> don't, /hurd/console takes care of that
<gnu_srs> is settrans /dev/vcs /hurd/console correct?
<teythoon> yes
<sjbalaji> What are those underlying directories representing ?
<teythoon> the hurd console is a console multiplexer
<teythoon> bringing multiple virtual consoles to the hurd
<teythoon> # showtrans /dev/tty1
<teythoon> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
<gnu_srs> aha: console -d vga -d pc_mouse --repeat=mouse -d pc_kbd
--repeat=kbd -d generic_speaker -c /dev/vcs
<gnu_srs> task c1120e70 deallocating an invalid port 1782, most probably a
bug.
<sjbalaji> teythoon: Is it that /dev/tty1 has multiple translators ?
<teythoon> no
<teythoon> exactly one translator is bound to any given node in the vfs
<gnu_srs> something is strange with the hurd console: booting with it
enabled still runs the mach console, halting:
http://paste.debian.net/79438/
<teythoon> what is strange about taht ?
<gnu_srs> when starting the hurd console: task c1120e70 deallocating an
invalid port 1782, most probably a bug.
<teythoon> so ?
<gnu_srs> and the paste when halting: twice
<teythoon> that is a known issue
<gnu_srs> with the hurd console?
<teythoon> how do you know it's the hurd console ?
<teythoon> that message comes from the kernel
<teythoon> currently, it is not possible to tell which process is
responsible
<teythoon> b/c the task is given as a pointer to the kernel task structure
<teythoon> not as a pid
<gnu_srs> I don't ,it is triggered by it at least
<teythoon> currently there is no way to map the former to the latter
<teythoon> why do you think it's a problem ? is something not working as
expected ?
<gnu_srs> maybe a reproducible way to hunt that bug!
<teythoon> we have one already
<teythoon> it happens every time the hurd boots
<gnu_srs> yes, hurd console does not start, even when enabled:-(
<teythoon> then please say so ;)
<gnu_srs> I did: (11:23:30) srs: something is strange with the hurd
console: booting with it enabled still runs the mach console, halting:
http://paste.debian.net/79438/
<teythoon> where do you say that the hurd console did not start ?
<gnu_srs> maybe it is easier to hunt the bug in an already booted system
<teythoon> you just said that the mach console is still active, wich it is
even if the hurd console starts
<teythoon> yes
<teythoon> please start the hurd console by hand
<teythoon> -d current_vcs -c /dev/vcs -d vga -d pc_kbd --keymap us
--repeat=kbd -d pc_mouse --protocol=ps/2 --repeat=mouse
<teythoon> err
<teythoon> /bin/console -d current_vcs -c /dev/vcs -d vga -d pc_kbd
--keymap us --repeat=kbd -d pc_mouse --protocol=ps/2 --repeat=mouse
<gnu_srs> when I log in I have the mach console not the hurd console
<teythoon> yes, log in as root, then run that command
<gnu_srs> I've done that: (11:10:27) srs: aha: console -d vga -d pc_mouse
--repeat=mouse -d pc_kbd --repeat=kbd -d generic_speaker -c /dev/vcs
<gnu_srs> please read?
<teythoon> and you discovered in that process that /dev/vcs lacked a
translator record
<teythoon> did you run it again after fixing that ?
<gnu_srs> the reply was: (11:10:27) srs: task c1120e70 deallocating an
invalid port 1782, most probably a bug.
<teythoon> well, if you are feeling that what i ask you to do is
unreasonable, i'm not sure how i can help you
<gnu_srs> yes, the translator was running!
<teythoon> you could hunt down the port deallocation bug, that'd be awesome
and most welcomed
<teythoon> but i don't believe it is causing your console malfunction
<gnu_srs> I did what you asked for??
<gnu_srs> I'll do it again!
<gnu_srs> ok, now I don't get that error, but still no hurd console? the
process is running, logging out and then in, no hurd console.
<gnu_srs> not possible in serial console?
<teythoon> no, the hurd console is displayed using the graphic card
<teythoon> you asked for that with -d vga ;)
<teythoon> not sure if there are any other display drivers
<teythoon> when you asked whether you can use the serial line, i assumed
you used both qemus graphic terminal and a serial console
<teythoon> try kvm ... -serial telnet::1236,server,nowait, then use telnet
localhost 1236 to connect to the serial console
<teythoon> then, you can start the hurd console over the serial console and
see whether that worked
<gnu_srs> OK; that's what I asked before. I tried with the graphic one,
I'll try again
<gnu_srs> telnet output is empty
<gnu_srs> frozen
<teythoon> did you start a getty there ?
<gnu_srs> in hurd?
<teythoon> b/c if you dropped the console=com0 argument from you gnumach
command line, the mach console will be put on the vga screen, not on the
serial console
<gnu_srs> I dropped console=com0 from grub.cfg, yes
<teythoon> ok
<teythoon> so simply no one is talking to the serial port anymore
<teythoon> did you try to start the hurd console ?
<gnu_srs> I did before, can do it again
<gnu_srs> startin the HC blanks the screen, and freezes the vga output:-(
ssh still working
<teythoon> hm
<teythoon> try ps Ax | grep tty, are there any term servers running for
/dev/tty1..6 ?
<gnu_srs> lplenty of them: http://paste.debian.net/79442/
<teythoon> good, even gettys are there
<gnu_srs> and the console translator runs
<teythoon> hm
<gnu_srs> root 1224 5 7 months /hurd/console
<gnu_srs> root 1227 1226 7 months /bin/console -d vga -d pc_mouse
pc_mouse -d pc_kb...
<teythoon> yes, everything looks good
<teythoon> just to be sure, you are currently using the qemus graphical
frontend, right ?
<gnu_srs> yes
<teythoon> hm :/
<teythoon> gnu_srs: do you see loginpr processes ?
<gnu_srs> nope
<teythoon> hum
<teythoon> this strikes me as odd
<teythoon> on my system, i see no gettys but only loginpr processes
<teythoon> this is b/c the hurd getty does little other than to print some
text and run the login program
<teythoon> but on your system the getty sticks around
<teythoon> is /sbin/getty really the hurd getty? it's easily recognized by
its crappieness:
<teythoon> /sbin/getty --help || echo $?
<teythoon> 1
<gnu_srs> 1
<teythoon> hm
<teythoon> still funny though
<teythoon> you could try to run the hurd console, then run a getty manually
<teythoon> e.g. /sbin/getty 38400 tty1
<gnu_srs> from the ssh login?
<teythoon> yes
<gnu_srs> then the graphic display is back showing the loin prompt:P
<teythoon> weird
<teythoon> well, so most things work
<teythoon> that's a good thing
<teythoon> funny that hurds getty should get stuck like this
<gnu_srs> and the terminal is hurd:-)
<teythoon> any chance you can produce a stack trace of one of your getty
processes ?
<gnu_srs> how?
<teythoon> gdb --pid=the_pid /sbin/getty
<teythoon> then, do bt like usual
<gnu_srs> so you mean tty2-6 are broken?
<teythoon> no
<teythoon> it's just for some reason your gettys do not behave nicely when
run from init
<gnu_srs> from running tty2: bt #0 0x01087b09 in ?? ()
<gnu_srs> #1 0x00000000 in ?? ()
<gnu_srs> not much
<teythoon> hm :/
<teythoon> indeed
<teythoon> our getty logs to syslog, can you see anythign of interest here
?
<gnu_srs> Jan 31 12:00:46 debian-openrc-20140123 rsyslogd-2066: could not
load module '/usr/lib/rsyslog/imklog.so', dlopen:
/usr/lib/rsyslog/imklog.so: undefined symbol: klogAfterRun
<gnu_srs> [try http://www.rsyslog.com/e/2066 ]
<gnu_srs> nothing tty releated
<teythoon> gnu_srs: oh, i just noticed, please look into auth.log, the
getty stuff ends up there
<gnu_srs> teythoon: http://paste.debian.net/79465/
<teythoon> well, that is interesting :)
<gnu_srs> /dev/tty1 not a directory?
<teythoon> for instance, yes
<teythoon> it says bad syntax if it was invoked in the wrong way, i.e. not
with exactly two arguments
<teythoon> that might have been you yourself, right ?
<teythoon> with getty --help i mean
<teythoon> for the not a directory message, please verify that
<teythoon> # showtrans /dev//tty1
<teythoon> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
<teythoon> and stat /dev/vcs/1/console says it's a character special file
<gnu_srs> I used exactly: /sbin/getty --help || echo $?
<teythoon> yes, that accounts for that bad syntax message
<gnu_srs> what so bad about that?
<gnu_srs> showtrans /dev//tty1
<gnu_srs> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
<teythoon> getty is so simple minded that it doesn't really parse its
arguments
<gnu_srs> stat: http://paste.debian.net/79469/
<teythoon> looks nice
<teythoon> everything looks nice, i'm at my wits end here
<gnu_srs> and everything works OK with sysv-rc?
<teythoon> yes
<teythoon> by the way, are you using the sysvinit init scripts or something
openrc related ?
<gnu_srs> openrc use all the scripts in /etc/init.d
<teythoon> actually, could you try to kill -HUP 1 ?
<gnu_srs> BTW: the dependency loop detector has found many loops in those
scripts
<gnu_srs> kill -HUP 1: nothing happens
<teythoon> ok, try to kill one of those gettys and see if the one that
respawns works
<teythoon> then again, the getty should try to reopen the device every
minute until it succeeds
<gnu_srs> getty tty1 and tty2 disappeared? kill -HUP tty3 respawns
immediately
<gnu_srs> now no getty processes are left?
<gnu_srs> /dev//tty4: Not a directory etc?
<teythoon> sorry, i should have expressed myself more clearly
<teythoon> kill -HUP 1 sends a SIGHUP to sysvinit, this makes it reload
it's configuration
<teythoon> when i said kill some getty, i meant just kill some_pid
<teythoon> when you said 'kill -HUP tty3 respawns immediately', did you
mean you killed the getty that was listening on /dev/tty3, and then a new
one appeared and you got a login prompt at tty3 ?
<gnu_srs> a new pid appeared, the login prompt is on tty1
<gnu_srs> this one? /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
<teythoon> i'd like to invite you to look at daemons/getty.c
<gnu_srs> not a big piece of code: anything specific?
<teythoon> no, just look what it roughly does
<gnu_srs> not a directory is not coming from that code
<teythoon> correct
<gnu_srs> it execl-s login
<teythoon> yes
<teythoon> inevitably
<teythoon> but you do not observe this
<gnu_srs> how come when they are running?
<teythoon> this is the question that you will have to answer in order to
make any progress
<gnu_srs> I killed only one of them: kill -HUP 1031 and they all
disappeared
<teythoon> i thought along these lines: the most obvious way to stall getty
is if it never exits that loop
<teythoon> so i guessed it might be failing to open the device
<teythoon> we already observed that getty works fine if invoked by you
manually
<teythoon> the question thus is, what is different when getty is invoked by
init ?
<teythoon> if a process started by init in this way is killed, init will
restart it
<teythoon> please note, that if anyone says kill that process, she means
send a signal that results in process termination
<teythoon> and while sighup causes processes to die if the signal is not
handled, it is not the ideal signal to kill processes
<teythoon> b/c some processes handle sighup
<teythoon> like sysvinit, which reloads its configuration
<teythoon> many daemons do this
<teythoon> see 'man 7 signal' for how signals affect processes
<gnu_srs> sorry, have to leave for now, bbl and thanks a LOT so far:)
<teythoon> ok :)
<teythoon> you are welcome :)
<gnu_srs> teythoon: I'm back but cannot spend to much time on this
tonight. Maybe you should try it yourself, do you want another image on
my box?
<teythoon> it'd be nice if you put your packages somewhere
<gnu_srs> there are no special packages sysvinit (-46) and openrc (-8)
<teythoon> surely openrc with some patches ?
<gnu_srs> from #openrc: (17:37:41) srs: start with sysvinit and make it
work first!
<gnu_srs> (17:28:43) srs: zigo: Then I copied that working image to
another, and changing hostname, and continued from there.
<gnu_srs> openrc with the hurd patches for /lib/rc/sh/init.sh (v8 should be
available from experimental by now)
<teythoon> sweet :)
<teythoon> gnu_srs: maybe it was just some weird issue with your system
<teythoon> i just switched to openrc and everything seems to just work
<teythoon> i'll redo what i just did more cleanly to get a clean test vm...
<gnu_srs> nice:)
<gnu_srs> teythoon: And you got the hurd console?
<teythoon> heh, i believe so >,<
<teythoon> i didn't see it b/c i was using --nographic
<teythoon> but ps Ax looked alright
<teythoon> hrm
<teythoon> gnu_srs: i can reproduce your trouble, umount still strips the
translator record from /dev/vcs
<teythoon> at system shutdown time
<gnu_srs> so that's the reason. Additionally I have to issue halt twice
from a ssh login, see http://paste.debian.net/79517/
<teythoon> funny indeed
<teythoon> gnu_srs: i can reliably recover the hurd console by doing
<teythoon> settrans /dev/vcs /hurd/console && service hurd-console restart
&& pkill getty ; sleep 5 ; pkill getty
<teythoon> humm, as you say, halt doesn't work
IRC, OFTC, #debian-hurd, 2014-02-01
<pere> I've just uploaded a new new sysvinit package to experimental, with
all the latest hurd fixes.
IRC, freenode, #hurd, 2014-02-01
<gnu_srs> 17:53:28< teythoon> settrans /dev/vcs /hurd/console && service
hurd-console restart && pkill getty ; sleep 5 ; pkill getty
<gnu_srs> teythoon: Any ideas on how to solve this?
<teythoon> gnu_srs: yes, i have that on my todo list
<gnu_srs> so it is not an openrc problem?
<teythoon> gnu_srs: no
IRC, freenode, #hurd, 2014-02-01
<teythoon> start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0]
exec init proc au
<teythoon> thtask with pid 6 deallocating an invalid port 134517370, most
probably a bug.
<teythoon> :)
<teythoon> pid 6 is exec o_O
<gnu_srs> teythoon: Nice to see that you added pid numbers for error
print-outs:)
<gnu_srs> so the boot error comes from the exec sever?
<teythoon> so it seems
<gnu_srs> server*
<gnu_srs> have you found where?
<teythoon> no
IRC, OFTC, #debian-hurd, 2014-02-02
<pere> but when I install the new packages, and run update-alternatives
--config runsystem to select sysv, the boot fail with: start ext2fs: Hurd
server bootstrap: ext2fs[device:hd0s1] exec init proc authtask c1128dc8
deallocationg and invalid port 134517370, most probably a bug.
<pere> was that the wrong approach?
<pere> is there some way to recover when hurd fail to boot with sysvinit?
<pere> I was able to boot in recovery mode. :)
<pere> and this time sysvinit booted. saw a segfault message just after
sysvinit started, no idea what caused it.
<pere> looks like it is startpar that segfaults.
<pere> looks like the invalid port message come every time, no matter if
the boot hang or not.
<pere> I was wrong. it isn't startpar segfaulting, it is something in
rcS.d/.
<pere> bootlogd is the process segfaulting at boot.
<pere> looks like the boot success rate is 30% or so.
<pere> reported bootlogd problem as <URL: http://bugs.debian.org/737375 >.
I really miss valgrind. :)
<teythoon> pere: yes, the invalid port message is from the exec server
<teythoon> pere: i see the hurd boot process hang sometimes, no matter if i
use sysvinit or not
<teythoon> i believe it's a race condition in the ext2fs, not sure though
<pere> teythoon: but did the frequency of the hang go up with sysvinit or
not? to me it seem like that.
<teythoon> pere: yes, i believe it got worse
<teythoon> what hangs is fsysopts --update /
<teythoon> runsystem.sysv does that quite early
<pere> able to debug it?
<pere> I like the fact that runsystem.sysv set up ip at boot time, while
with .gnu, I have to run dhclient /dev/eth0 manually
<pere> it is quite confusing that hurd got two init processes with
sysvinit. one as pid 1, and another that seem to be the parent of all
internal stuff. perhaps the latter could be renamed to hurd-system or
something like that?
<pere> "sleep 0.2 # Work around a race condition (probably in the root
translator)." do not look too good...
<pere> (I increased from 0.1 to see if it help me. :)
<teythoon> did it ?
<teythoon> i plan to rename /hurd/init to /hurd/startup
<pere> nope. :)
<pere> five boots in a row hung. :(
<pere> still no go...
<teythoon> are you using a vm or real hardware ?
<pere> vm
<pere> kvm, via virt-manager, to be exact.
<teythoon> me too
<pere> on the sixt boot, after waiting a long time between try 5 and 6
(gave up a bit), it booted.
<pere> sleep 1 did not help either.
<teythoon> :(
<teythoon> well, it's not *that* bad for me
<teythoon> in fact recently it has been a lot better
<teythoon> you might try my packages
<teythoon> pere: here https://darnassus.sceen.net/~teythoon/hurd-ci/
<pere> teythoon: tested it, and it seem to solve the problem.
<pere> is also rid of the strange error at the start.
<pere> teythoon: your packages even work without the sleep 0.1, at least
some of the time. :)
<pere> hm, but the success rate without sleep 0.1 is very low. I was able
to boot once, and never again. :(
<teythoon> pere: yes, i fixed the spurious port allocation today :)
<teythoon> pere: nice to hear that the sleep 0.1 i put in does increase
your chance to boot as well
IRC, freenode, #hurd, 2014-02-02
<teythoon> gnu_srs: i found the spurious port deallocation :)
<gnu_srs> Cangrats:-D
<teythoon> trouble is, i introduced it >,<
<gnu_srs> Congrats*
<gnu_srs> Ah, you did?
<teythoon> gnu_srs: yes, in debian/patches/exec_filename_fix.patch
<teythoon>
https://darnassus.sceen.net/cgit/teythoon/packaging/hurd.git/commit/?id=6da3e0be8fde0594bd84a13536d9d93048186790
* teythoon . o O (diffs of diffs are trippy :)
IRC, freenode, #hurd, 2014-02-03
<braunr> teythoon: oh nice, you found that bug :)
<teythoon> braunr: yes, once i knew where to look it was easy to fix ;)
IRC, freenode, #hurd, 2014-02-05
<teythoon> i wonder why the port deallocation bug made the system hang when
the libc was compiled with the newer gcc
<braunr> teythoon: so it was indeed the problem ?
<teythoon> braunr: youpi said so, yes
<braunr> oh right
experimental, glibc 2.18 vs. GCC 4.8?
IRC, OFTC, #debian-hurd, 2014-02-03
<pere>
http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html
<teythoon> :)
<teythoon> pere: sounds like your hurd-console isn't running and there is
no getty on the mach console
<teythoon> pere: you could add sth like 8:2345:respawn:/sbin/getty 38400
console to your inittab
<pere> I'd rather wait until the hurd porters get it right in the debs. :)
<pere> I suspect upgrading the downloadable image to use the latest
packages also would help a lot.
<pere> with upgraded packages, /proc is working and pstree, pkill, top, etc
is working out of the box. :)
IRC, OFTC, #debian-hurd, 2014-02-04
<pere> I just uploaded sysvinit with hurd support to unstable. :)
IRC, freenode, #hurd, 2014-02-04
<gnu_srs> teythoon: Hi, the segfault during boot is coming from bootlogd,
see bug #737375
<gnu_srs> also the output on the console is from there: end_request: I/O
error, dev 02:00, sector 0
<teythoon> gnu_srs: interesting :)
<teythoon> gnu_srs: i believe the end_request message comes from gnumach
<youpi> yes, that's just a floppy disk access attempt
<gnu_srs> might be so yes
<youpi> it's not a "might", it's sure :)
<youpi> dev 02:00 is the flopy
<gnu_srs> k!
glibc IOCTLs, TIOCCONS
IRC, OFTC, #debian-hurd, 2014-02-04
<zigo> Each time I upgrade my hurd box, I cannot login into it ...
<zigo> No login prompt.
<zigo> WTF is going on?
<zigo> How to fix?
<teythoon> zigo: most likely your hurd console is not running and there is no getty started for the mach console
<zigo> teythoon: How to fix? (note: I already have the partition mounted in a loopback)
<zigo> Or maybe go in recovery mode?
<teythoon> depends
<teythoon> do you use sysvinit ?
<teythoon> do you use the hurd packages from hurd-ci ?
IRC, OFTC, #debian-hurd, 2014-02-05
<zigo> teythoon: Sorry, didn't see your reply. I just used the Hurd image,
untar it, and apt-get update / dist-upgrade. That's it, nothing more or
less.
<zigo> teythoon: I obviously would like to install sysvinit, and later
OpenRC. That's the reason why I'm running Hurd: to make sure OpenRC works
with it without issues.
<zigo> teythoon: It seems it "sometimes work" or what???
<zigo> I was able to repair it using the recovery mode, it seems.
<zigo> grrr...
<zigo> I got this issue again, again and again ...
<zigo> Sometimes, got the tty1, sometimes, it doesn't appear.
<zigo> That's REALLY frustrating.
<pere> zigo: and yes, the success rate for boot is not 100%. it increases
a bit by using the packages teythoon created at hurd-ci.
<pere> apparently some race condition somewhere.
<zigo> pere: So, I should just try and reboot again and again ?
<zigo> pere: Is it improving after switching to sysvinit?
<pere> once I had to boot six times before I got it running...
<pere> I was told that the race involves a call to fsysopts, and that the
success rate with sysvinit was smaller because fsysopts command was
called earlier. I can not confirm nor deny this.
<pere> with the latest packages from hurd-ci the success rate is almost
100% again.
<zigo> pere: Where do get that?
<pere> zigo: see <URL:
http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html
>
<zigo> pere: What's the "update-alternatives --config runsystem" for?
<pere> to switch to sysvinit
<zigo> Right, that's what I was missing then! :)
<pere> the new sysvinit version in unstable was built for hurd one and a
half hour ago. so soon hurd users can skip experimental for that.
<zigo> pere: I've just succeeded in booting with OpenRC! :)
<zigo> Though this console pb is REAAAALLLYYYY getting on my nerves! :)
<zigo> Also, any idea why we don't get the nice colorfull output when
booting?
<zigo> When booting with OpenRC, I've noticed that the dependency loop
detects some loops with the hurd-console thing.
<teythoon> zigo: good to hear that you got it working
<teythoon> the console problem is the following
<teythoon> when you shutdown using sysvinit, the system will run umount -a
<teythoon> it will then mistake some translators (like the one on /dev/vcs)
for file systems and remove their passive translator records
<teythoon> you can fix this by running '/usr/lib/hurd/setup-translators -k
-p'
<teythoon> you can avoid it for the time being by using reboot-hurd or
halt-hurd
<pere> teythoon: btw, how often is the hurd boot image available for
download updated?
<teythoon> not very often
<zigo> teythoon: Can I run '/usr/lib/hurd/setup-translators -k -p'
mounting my hurd image in a chroot?
<zigo> Hum...
<zigo> Probably better to do that in the recovery mode, no? :)
<youpi> dpkg-reconfigure hurd
<youpi> would be easier to type :)
<youpi> but we really need to fix that /dev/vcs unmounting
<pere> missing working getty and missing symlink from /run/mtab to
/proc/mount are the most serious problems I still see.
<zigo> The recovery mode doesn't work with OpenRC ! :(
<zigo> (it does in kFreeBSD and Linux, not with hurd ...)
<zigo> What happens is that it continues to runlevel 2.
<zigo> How can I fix then?
<youpi> pere: missing working getty?
<youpi> I don't see what issue you are referring to
<youpi> about the missing symlink, I'm wondering what is supposed to add it
<youpi> zigo: I don't know if anybody investigated it yet
<pere> youpi: yes, after boot there is no login prompt.
* pere have no idea, suspect a script in initscripts.
<zigo> youpi: I'm reffering to the fact that I have no login prompt after
boot, and that I don't know how to fix, since I don't have a recovery
mode to my disposal anymore.
<youpi> pere: but is the console started?
<youpi> (I mean the hurd console)
<zigo> pere: I suspect a wrong dependency, which OpenRC by the way, prints.
<youpi> pere: otherwise, unless you have a /dev/console getty in
/etc/inittab, it's expected you don't have a prompt
<youpi> zigo: add
<youpi> c:23:respawn:/sbin/getty 38400 console
<youpi> to your /etc/inittab
<teythoon> youpi: yes, we need to get that fixed
<youpi> grrrr
* youpi wanted to change the image file on people.d.o
<youpi> but I can't do that without downloading it on my laptop, to be able
to modify it
<youpi> I would have been, if people was a hurd system :)
<teythoon> the proper way to fix this is to implement the get_source stuff
and get rid of the heuristic in mtab.c
<pere> youpi: nope, no console process running.
<youpi> then that's why, /dev/vcs got unmounted
<pere> I already have a console getty in inittab. got it from the last
sysvinit package
* youpi should have brown-bag-fixed these bugs before this week-end
actually :)
<youpi> pere: but you don't get a getty prompt on the mach console? I don't
understand why
<youpi> it does work for me
<teythoon> brown-bag-fixed ?
<zigo> youpi: Adding that in /etc/inittab didn't fix anything.
<youpi> yes, ugly hacks uploaded to debian-ports
<youpi> zigo: even with rebooting?
<youpi> could you snapshot your screen so we can make sure what you are
actually getting?
<zigo> youpi: I did it mounting my partition in a loopback...
<zigo> Then booted up, and still couldn't see the console prompt.
<youpi> ok, but please take a snapshot, so we are sure what is actually
happening
<youpi> whether the console starts, etc.
<pere> that info passed out of the screen and is not shown after my boot,
at least.
<youpi> which info?
<youpi> again, please take a snapshot of the screen
<youpi> otherwise we are just guessing, and that's never good for debugging
<zigo> Maybe you'll find this interesting: http://paste.debian.net/80246/
<zigo> This is the output of OpenRC booting and detecting dependency loops
in the LSB header scripts.
<pere> youpi: the info about the console being started or not. I'll show
you, give me a minute.
<youpi> zigo: well, that shouldn't be more problems than the dependency
loop already existing between rc.local and rmnologin
<pere> youpi: any loop is a fatal problem.
<youpi> how come the rc.local vs rmnologin is not a problem ?
<zigo> With sysv-rc in Debian, there's all sorts of loops that are just
silent.
<pere> I have not seen that loop on my linux system, so I am unsure what
you talk about.
<youpi> (the actual issues is simply that all three use Required-start:
$all, and thus all depend on each other)
<zigo> That's a huge pb IMO.
<youpi> pere: well,
<pere> zigo: show me one?
<youpi> rc.local:# Required-Start: $all
<youpi> rmnologin:# Required-Start: $remote_fs $all
<zigo> Yeah, the $all is just *bad*.
<pere> that is no loop.
<zigo> I do believe we should implement a lintian warning about it.
<pere> sure, $all do not behave the way most people expect, and should be
avoided as much as possible.
<pere> any other loops?
<youpi> no
<youpi> (not that I know of)
<pere> youpi: sending you the screenshot via irc.
<youpi> uh, long time no use dcc send, I don't even know where it sent it
to :o)
<pere> ok. aborting and trying another approach.
<pere> http://www.picpaste.com/booted-herd.png
<youpi> ok, so boot didn't actually finish
<youpi> that's why you don't get gettys or hurd-console (which is last)
<youpi> there must be some init script hanging in the meanwhile
<pere> logging in via ssh show no running startpar process, so I doubt that
is the case.
<pere> syslog contain this: Feb 5 10:10:27 hurdtest console[808]: Console
library initialization failed: Not a directory
<youpi> that is due to /dev/vcs not mounted
<youpi> but that should have not prevented the boot from completing...
<pere> the boot is completed, as far as I can tell.
<youpi> you can disable the hurd console in /etc/defaults/hurd-console
<youpi> do you have gettys running?
<pere> no such file.
<youpi> oops, -s
<pere> http://paste.debian.net/80251/
<teythoon> pere: check your /etc/inittab, is there a getty for the mach
console ?
<youpi> he said yes earlier
<teythoon> oh ok
<teythoon> i wonder why it doesn't show up then
<youpi> same for me
<teythoon> if the getty cannot open the device, it will loop
<pere> ah, I was wrong. the inittab is not the one I thought. the current
one is after a reinstall, while I checked the content before that.
<teythoon> pere: check /var/log/auth.log
<pere> there is indeed no console entry in /etc/inittab. I thought it
would be copied into place during upgrades?
<teythoon> not if it exists
<teythoon> iirc
<youpi> indeed
<pere> ah, great. "cp /usr/share/sysvinit/inittab /etc/inittab" and a
reboot fixed it. :)
<youpi> phew :)
<pere> it really should try harder to update the inittab on hurd to a
working one.
<teythoon> didn't i do something like this to fix the getty path ?
<pere> yes. that was the code I expected to solve this.
<teythoon> it didn't work ?
<pere> well, I had the wrong inittab file...
<pere> btw, do hurd have the needed syscalls for bootlogd to work?
<teythoon> i haven't looked at bootlogd yet
<pere> would be nice to have a text dump of the boot when trying to figure
out what went wrong.
<teythoon> yes, that'd be nice
<youpi> pere: could you blacklist /dev/vcs in umountfs, just like already
done for /proc|/dev|/.dev etc. ?
<youpi> so at least that case, which is really problematic, gets fixed now,
and not have to wait for another, more hurdish solution
<pere> youpi: just send patches to bts, and I'll pick it up from there.
<teythoon> nice. i'll work on the proper solution. bbl
<rleigh> teythoon: Can we add those translators to the exclusion lists in
umount[nfs]?
<rleigh> Sorry, I just noticed youpi's comment. I'm a bit behind.
<heroxbd> rleigh: good to see you! are you back to the keyboard? fully
recovered?
<rleigh> Not quite fully, but on the mend, thanks!
<heroxbd> :]
<pere> rleigh: yeah, good to see you again. I got a burst of energy and
brushed a bit on sysvinit in your absence. :) Even revitalized the
#pkg-sysvinit channel. :)
<rleigh> pere: Yes, I saw all the commit emails flying by!
<rleigh> I realistically won't be doing much for several weeks at least
though, I'm afraid.
<pere> no worries. spend your time getting well. :) it would be great to
have you on #pkg-sysvinit, though. :)
<rleigh> I'll join, no worries. I should add it to my irssi config so I
can't forget!
<heroxbd> teythoon: serial console always works, right? no matter how
hurd-console behaves.
<teythoon> heroxbd: yes
<teythoon> but you need a getty on it
<youpi> well, just like on linux :)
<teythoon> yes
<teythoon> almost
<teythoon> on mach, we have the mach console. by default that is put on the
vga screen, but you can make mach put it on a serial port using the
gnumach command line flag console=comX
<youpi> well, just like on linux :)
<heroxbd> understood, thanks!
<teythoon> oh, i didn't realize linux has this as well
<heroxbd> teythoon: you'll use it a lot on a embedded system
<heroxbd> an*
<teythoon> ok
<gg0> plus, seems it can't cleanly umount /, at boot it fsck's it, fixes it
and auto-reboot
<youpi> it's odd that / doesn't get unmounted, don't you get a message at
"notifying ext2fs device:hd0s1 of shutown" ?
<gg0> on console last 3 lines on halt are
<gg0> Deactivating swap...swapoff: /dev/hd0s5: 4193208k swap space
<gg0> done.
<gg0> Unmounting local filesystems...done.
<gg0> INIT: no more processes left in this runlevel
<youpi> is this on reboot or on halt?
<gg0> halt
<youpi> then you should also be getting the "notifying" messages, as well
as "In tight loop: hit ctl-alt-del to reboot" message
<gg0> it umounts uncleanly on reboot too
<youpi> if you don't wait for these, there's little wonder it's not
properly unmounted
<gg0> i waited many seconds, time to rewrite 3 lines above for you for
instance (not a fast typist)
<gg0> on reboot it's harder but iirc they don't appear as well
* gg0 rebooting again
<gg0> need to wait it finishes fsck'ing
<gg0> (i should resoldering my serial cable to get back to lazily c&p)
<gg0> -ing
<gg0> many Give root password messages then
<gg0> Give root password for maintenance
<gg0> (or type Control-d to continue):
<gg0> INIT: Id "z6" respawning too fast: disabled for 5 minutes
<gg0> INIT: no more processes left in this runlevel
<gg0> i'll wait 5 mins to see what happen
<gg0> ok another dozen of Give root password and same couple of INIT above
<gg0> no, just the first INIT
<youpi> so z6 doesn't work
<youpi> i.e. /sbin/sulogin (see /etc/inittab)
<youpi> check out why that is
discussion, IRC, freenode, #hurd, 2013-06-25,
coreutils' df.
<youpi> [...] depends on coreutils actually building
<youpi> which depends on putting back a login package from the shadow
source package
<pere> are someone on that task?
<youpi> no idea
<youpi> IIRC I've mentioned the issue on the lists like months ago
<youpi> but probably nobody took the tas
<youpi> k
<youpi> basically it means fixing any bug that login or su from the login
package would have
<youpi> and then properly handle the migration from hurd-provided versions
to login-provided versions
<youpi> and then we would be able to build coreutils
<pere> which BTS report is this?
<youpi> I don't know if any report has been written about it
<youpi> perhaps simplest would be to build the login package, but not its
bin/login
<youpi> it seems hurd's getty uses special options of hurd'slogin
<youpi> that's probably the easiest way to go
<gg0> sulogin seems to work fine but it shouldn't even called:
<gg0> # Normally not reached, but fallthrough in case of emergency.
<gg0> z6:6:respawn:/sbin/sulogin
<gg0> +be
<pere> I suspect a good fix is to provide a new init.d script in the hurd
package adding the symlink for hurd.
<gg0> umountfs gets stuck at "Will now umount local filesystem:settrans
-apgf /lib/rc/init.d"
IRC, freenode, #hurd, 2014-02-05
<gnu_srs> teythoon: Any ideas why I have to issue halt/reboot twice to make
the command succeed (from ssh login)
<gnu_srs> Is it the same issue with sysv-rc?
<teythoon> no
<gnu_srs> BTW: The segfault when booting came from bootlogd (wrong
parameters, Linux/~Linux), removing that one fixed it;-)
IRC, freenode, #hurd, 2014-02-06
<youpi> teythoon: we really need to find the boot issue for which you added
a sleep 0.1 in runsystem.sysv
<youpi> apparently I had to move it above the mach-defpager startup, to get
a system that boots most of the time...
<azeem> did somebody look at
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html
?
<braunr> azeem: interesting
<azeem> braunr: was mentioned here: http://lwn.net/Articles/584428/
<azeem> " Systemd won't work for them, that's for sure, but nosh as a
systemd unit file compatible alternative could. "
<braunr> "I'm also very interested in seeing a discussion where the Debian
Hurd and BSD porters weigh in for themselves"
IRC, OFTC, #debian-hurd, 2014-02-06
<gg0> on halt/reboot it can't remount readonly root because it's busy, what
makes it busy?
<gg0> by keeping /lib/rc/init.d mounted (like /dev/vcs) it shuts down
properly
<youpi> I don't know about such directory
<gg0> so seems that failed readonly remount is not a real problem because
at the end it runs halt-hurd/reboot-hurd which umount root properly
<youpi> yes
<gg0> afaiu it's a tmpfs where openrc copies "itself", kind of work
directory
<gg0> by removing it, it can't continue working
<gg0> at boot some messages are about its creation/population
<pere> why do init.d/hurd-console depend on $all? In most cases, depending
on $all is not giving you want you expect.
<youpi> because we prefer to start the console (and thus clear all the
screen) only after the boot has finished
<youpi> otherwise the console output will be messed up by the end of the
boot messages
<teythoon> youpi: there has to be a better way
<teythoon> b/c the way it is now, if one spawns a getty on the mach
console, it will mess up the hurd console as well
<youpi> well, we do want mach messages printed even with the hurd console,
at least
<teythoon> i once thought that instead of printing them the kernel could
send messages to a registered userspace daemon that could e.g. send them
to syslog
<youpi> that requires syslog to be working at all
<pere> changing $all to $local_fs seem to work fine here.
<youpi> when the kernel cries out, we'd better always be able to hear it :)
<youpi> pere: but then you have the bootup messages in the middle of the
console, don't you?
<pere> not as far as I can tell. look just the same as before.
<youpi> well, on my box it seems that it gets to start after other daemons,
by luck
<youpi> ah, perhaps getty actually clears the tty?
<youpi> then that would be ok
<teythoon> youpi: i don't think it does
<youpi> well, somehow something clears the output at least
<teythoon> i thought he hurd console does this
<youpi> it does on startup, yes
<youpi> but if it starts before other daemons
<youpi> the damons startup output gets over it
<youpi> one sees the console clear the screen, then get daemon startup
messages, and then the screen gets cleared again before the login prompt
appears
<teythoon> interesting, i haven't seen this happening
<youpi> it seems like it happens when emitting text on /dev/tty1, the
console will then clear the screen to make the way for the new output
<youpi> and since that happens on getty startup, it happens to be after all
daemon startup
<youpi> yes, that's what happens
<youpi> so considering this, I'm fine with starting the console earlier
<youpi> getting a display glitch seems to have been acceptable on Linux for
years :)
<youpi> (during boot, I mean)
<teythoon> ok
<gg0> anyone else tried openrc?
<gg0> 15:20 < pere> yes, it did not umount properly.
<gg0> 15:36 < gg0> reboot or halt? it takes few seconds to actually
reboot/halt since the last message from openrc
<gg0> 15:39 < gg0> any typo adding such path?
* gg0 likes cross-channel pasting
<gg0> anyone else keeps getting unclean umounts even after applying
http://paste.debian.net/plain/80386/ ?
<teythoon> gg0: yes, me. worked fine, it didn't shut down properly though
<gg0> here works like a charm
<gg0> what do you mean by properly?
<gg0> i see first it can't remount root readonly but at least by not umount
path in question it continues executing scripts till actually shut it
down with something like {halt,reboot}-hurd
<gg0> *not umounting
<gg0> *shutting
<teythoon> for me it did not shut down
<gg0> you mean don't you get classic press ctrl+alt+canc to reboot message?
<teythoon> yes
<teythoon> from my perspective (and from /hurd/init's), that's not shutting
down
<teythoon> as in it did not call reboot(2)
<gg0> what are configuration not to miss besides switching runsystem to
sysv one?
<gg0> *configuration steps
<teythoon> no idea, i did nothing else but to switch to runsystem.sysv and
to install openrc thus replacing sysv-rc
<gg0> can you paste shutdown messages somewhere?
<teythoon> sure
<gg0> .o(world is failing, /me can't debug teythoon :))
<teythoon> http://paste.debian.net/hidden/745071e6/
<gg0> in my case i just found out that /etc/init.d/umountfs tries to umount
/lib/rc/init.d where openrc scripts are
<gg0> what if you set VERBOSE and print REG_MTPTS? something like
http://paste.debian.net/plain/80570/
<gg0> there i got "settrans -apfg /lib/rc/init.d" which vanished with first
patch
<teythoon> http://paste.debian.net/80573/
<gg0> ok and if you apply first patch http://paste.debian.net/plain/80386/
<gg0> i.e. adding |/lib/rc/init.d to mount point to ignore
<teythoon> didn't help
<gg0> well output should change though
<teythoon> it does
<teythoon> but it still does not shut down
<gg0> paste please then
<teythoon> http://paste.debian.net/80576/
<teythoon> what did you expect ?
<gg0> did you unapply VERBOSE & print REG_MTPTS?
<teythoon> yes
<teythoon> no
<teythoon> well
<gg0> seems you do, if VERBOSE is set, it prints Will now unmount local
filesystems"
<teythoon> i restored a vm snapshot, and applied both patches
<gg0> instead of "Unmounting local filesystems"
<gg0> *seems you did
<teythoon> http://paste.debian.net/80577/
<teythoon> shall i do it again ?
<gg0> and what after "root@debian:/# halt" ? :p
<teythoon> 23:55 < teythoon> http://paste.debian.net/80576/
<teythoon> and openrc shouting lots of stuff about breaking dependencies
<gg0> please yes do it again
<gg0> if VERBOSE is set, it prints "Will now unmount local filesystems"
instead of "Unmounting local filesystems"
<teythoon> yes, you are right
<teythoon> still, it does not work
<teythoon> http://paste.debian.net/80579/
<gg0> i'm curious about the new REG_MTPTS, supposing /lib/rc/init.d has
been suppressed
<gg0> ok stop
<gg0> 23:47 < gg0> ok and if you apply first patch
http://paste.debian.net/plain/80386/
<teythoon> i did
<teythoon> well, i added that path
<gg0> i don't believe so, it should ignore it if added
<teythoon> did it fix the issue for you ?
<gg0> yes
<gg0> any typo in addition?
<gg0> obviously patch is against sysvinit source but you have to apply it
to /etc/init.d/umountfs
<teythoon> obviously
<gg0> isn't it time to tell me you are kidding me yet?
<youpi> pere: thanks for the upload. I happened to realized that since it
was in collab-maint, I could as well just commit changes, I hope it's ok?
<teythoon> gg0: root@debian:~# fgrep '/lib/rc/init.d' /etc/init.d/umountfs
/|/proc|/dev|/.dev|/dev/pts|/dev/shm|/dev/.static/dev|/proc/*|/sys|/sys/*|/run|/run/*|/lib/rc/init.d)
<gg0> /dev/vcs is missing, not the latest sysvinit version
<gg0> could this affect shutdown?
<teythoon> i know
<teythoon> possibly
<gg0> what if you also add /dev/vcs to path list?
<teythoon> what then ?
<teythoon> i don't mind /dev/vcs being
<teythoon> err, 'umounted'
<teythoon> i can handle that just fine
<gg0> i mean what happens if you add /dev/vcs to path list in
/etc/init.d/umountfs as you did with /lib/rc/init.d?
<gg0> what happens = how it shutdown
<teythoon> why would it be any different ?
<gg0> no idea, seems the only change you don't have
<gg0> i just know it fixes hurd console
<teythoon> i know it fixes the hurd console b/c i was the one who broke the
hurd console in the first place ...
<gg0> quite sure there's something wrong on your side
<gg0> if it's actually among those path to ignore, it can't be added to
REG_MTPTS
<gg0> my /proc/mounts http://paste.debian.net/plain/80583
<gg0> yours?
<gg0> i hope i'm not forgetting one change i did around
<gg0> teythoon: /proc/mounts ?
IRC, OFTC, #debian-hurd, 2014-02-07
<gg0> teythoon: sorry for pasting reversed patches
<gg0> please apply http://paste.debian.net/plain/80587, halt and paste
output + /proc/mounts
<pere> youpi: just fine. but please join us on #pkg-sysvinit and make sure
to follow the mailing lists.
<teythoon> gg0: no, sorry, i was perfectly able to use -R on your patches,
as demonstrated by the paste i send
<teythoon> i think i'll rather just wait for the next sysvinit package and
try it again
<gg0> teythoon: i don't doubt you are able, i'm sorry because i messed up
things
<gg0> /lib/rc/init.d should not go in $REG_MTPTS
<gg0> sysvinit 2.88dsf-48 just add /dev/vcs to not-to-umount paths and make
boot consider -s for single user, nothing about umounting filesystems on
halt/reboot
<pere> the /lib/rc/init.d/ change to umountfs seem to be the wrong one, as
it do not solve the problem for me. because of this, I have not applied
it to git.
<gg0> pere: could you try to apply http://paste.debian.net/plain/80587,
halt and paste output?
<gg0> well it applies to teythoon who doesn't have /dev/vcs
<gg0> */dev/vcs change
<gg0> pere: this one applies to -48
installed. http://paste.debian.net/plain/80615/
<gg0> given /lib/rc/init.d is added to not-to-umount paths it can't go in
REG_MTPTS
<pere> http://picpaste.com/halt-hurd-DVEVoHnr.png
<gg0> pere: you didn't apply it
<gg0> no messages from umountfs
<gg0> which is even more weird
<pere> well, patch claimed it did.
<gg0> normally it says "Unmounting local filesystems..."
<pere> checked the file, patch is applied.
<gg0> ok i think i got it
<gg0> patch is good. it just requires booting twice _and_ removing
non-patched /etc/init.d/umountfs.* if any
<gg0> patch = adding /lib/rc/init.d
<gg0> so
<pere> which files do you need to remove?
<gg0> /etc/init.d/umountfs.* and /lib/rc/init.d/started/umountfs.*
<gg0> do you have any?
<gg0> you should just have patched umountfs under both /etc/init.d/ and
/lib/rc/init.d/started/
<gg0> the latter is populate at boot, that's why i said twice to become
effective
<gg0> *populated
<gg0> but propably /lib/rc/init.d/started/umountfs can be fixed on the fly
<gg0> from start:
<pere> why do you need to remove these files?
<gg0> 1/ patch /etc/init.d/umountfs by adding /lib/rc/init.d to
not-to-umount path list
<pere> why are these files not ignored?
<gg0> 2/ remove /etc/init.d/umountfs.* if any (eg. .orig .new .whatever)
<gg0> pere: because it loads them at boot, you need it loads just the right
one
<gg0> 3/ reboot twice
<gg0> (3/ halt twice)
<pere> this sound very fishy to me.
<gg0> or 3/ fix umountfs files under /lib/rc/init.d/started as well
<gg0> that should make it shutdown properly right away
<pere> my halt still hang.
<gg0> pere: you have /lib/rc/init.d in both /etc/init/umountfs and
/lib/rc/init.d/started/umountfs and there are no umountfs.* around?
<gg0> problem seems to be it picks first it finds if there are more than
one
<gg0> well i could have been more precise: /lib/rc/init.d/started/umountfs
is a link to /etc/init.d one
<gg0> btw there must be just one and only one umountfs, patched
<gg0> pere: clean /etc/init.d, reboot/halt with reboot-hurd or halt-hurd,
then next sysv reboot/halt will be good
<gg0> you just need to leave patched umountfs under /etc/init.d alone
<gg0> patch has always been good, it just needs 2 reboots to be appreciated
<gg0> pere: do you have other /etc/init/umountfs* files besides patched
one?
<gg0> my guess is it takes the first and only the first which Provides:
umountfs
<gg0> 12:17 < pere> why are these files not ignored?
<gg0> 12:35 < gg0> my guess is it takes the first and only the first which
Provides: umountfs
<gg0> to confirm that, if you have umountfs and umountfs.orig, under
/started you'll find just umountfs.orig
<gg0> pere: how goes?
<gg0> teythoon: last ~40 lines
<gg0> i'm assuming you have any else umountfs.* under /etc/init.d. if you
just add /lib/rc/init.d path to the only umountfs there should not be any
problem
<pere> gg0: removing the umountfs.* files did not help, as far as I can
tell.
<pere> are you telling me that openrc caches all init.d scripts in
/lib/rc/init.d/ at boot?
<gg0> pere: yes, you can see them. which umountfs* do you have under
/lib/rc/init.d ?
<pere> the right one. :)
<gg0> only the right one?
<pere> just scared me to know that changes on the disk do not take effect
immediately with openrc.
<gg0> pere: only the right one?
<pere> yes
<gg0> here i screwed it up by forcing initscripts removal and reinstall to
reproduce it, then fixed it once again
<gg0> i should just improving the explaination :)
<gg0> pere: "removing the umountfs.* files did not help," so did you find
any?
<pere> yes, both .orig, .rej and .dpkg-old
<gg0> pere: ok you should find one of them linked under
/lib/rc/init.d/started then
<gg0> /lib/rc/init.d/started/umountfs.*
<pere> I removed them three boots ago. still halt hangs.
<gg0> pere: and current umountfs have /lib/rc/init.d in path list?
<gg0> *has
<pere> yes.
<gg0> pere: can you access via ssh to it before issuing halt?
<pere> that is how I access it normally.
<gg0> ok
<gg0> before halt df should list /lib/rc/init.d as well
<gg0> after halt it should not, do you confirm that?
<gg0> (ssh connection here is kept alive)
<pere> my ssh connection went down, but /lib/rc/init.d was mounted while it
was active.
<pere> to me it look like umountfs isn't executed at all during shutdown.
<pere> oh, well. got to work on other things now. :)
<gg0> it's correct getting no messages if there no filesystem to umount
<gg0> as it wouldn't be run at all
<zigo> pere: Hey, thanks for uploading sysv-rc -48 ! :)
<pere> you are welcome. :)
<gg0> i can't reproduce it on a VM :/ http://paste.debian.net/plain/80658/
<gg0> ehm no, same machive, successive halt
http://paste.debian.net/plain/80659/
<gg0> got stuck
<pere> are there any testet sysvinit patches for hurd lingering? I plan to
upload a new version tonight or tomorrow.
IRC, OFTC, #debian-hurd, 2014-02-08
<gg0> http://paste.debian.net/plain/80854/
<gg0> expected?
<gg0> do tmpfs and procfs need to be shown as types /hurd/tmpfs and
/hurd/procfs?
<gg0> or can they be "normalized"?
<gg0> domount mount_noupdate tmpfs shmfs /run tmpfs
-onosuid,noexec,size=10%,mode=755
<gg0> another one is why on linux options are nosuid,noexec ^, whereas on
hurd no-suid,no-exec,... ?
<rleigh> gg0: If they need generalising, we can add $nosuid/$noexec
etc. variables to mount-functions.sh and set them appropriately for the
currently platform.
<rleigh> current platform rather
<gg0> yeah, i ask just to understand what side people prefers modifying, in
this case hurd vs sysvinit
<gg0> btw in the meanwhile i got tmpfs takes options without '-' though it
shows them with '-' in proc/mounts
<gg0> rleigh: and thanks for pointing out what looking for, little hints
saves hours in my case :)
[IRC connection closed]
IRC, freenode, #hurd, 2014-02-08
<youpi> gnu_srs: the -49 version of sysvinit contains a fix for bootlogd
IRC, freenode, #hurd, 2014-02-09
<gnu_srs> (16:31:17) <youpi>: gnu_srs: the -49 version of sysvinit contains
a fix for bootlogd
<gnu_srs> Nice for kFreeBSD, for Hurd it doesn't matter if we get a
segfault or an error code saying it's not implemented :-(
<youpi> segfault vs error code is really not the same
<youpi> iirc bootlogd would ignore the error
<gnu_srs> Nevertheless, bootlogd is not usable on Hurd :(
<youpi> then fix it
IRC, OFTC, #debian-hurd, 2014-02-08
<rleigh> gg0: If the sames are set by hurd itself, then it makes sense to
adapt sysvinit to cope with that rather than altering hurd since that
would be a fairly major compatibility break. OTOH, adding support for the
Linux/FreeBSD names in addition to the hyphenated names would be good
from the point of view of better interoperability generally, not just for
sysvinit.
<rleigh> For now, getting sysvinit to support the Hurd names is easy
enough, and if you do add the Linux/FreeBSD names then the compatibility
stuff can be removed when that's available.
IRC, freenode, #hurd, 2014-02-11
<gnu_srs> Hi, still problems with hurd console under openrc: console:
Console library initialization failed: Not a directory
<gnu_srs> and /dev/vcs is there
<youpi> gnu_srs: but is it a directory?
<gnu_srs> the output of console -d vga -d pc_mouse --repeat=mouse -d pc_kbd
--repeat=kbd -d generic_speaker -c /dev/vcs gives the response above
<gnu_srs> looks like /dev/vcs is a file. How to recreate the directory
content?
<gnu_srs> I thought it should not be removed with the latest sysvinit
package (-49)
<gnu_srs> from -48 changelog: Tell init.d/umountfs to not umount /dev/vcs,
as it break the console on Hurd. Patch from Samuel Thibault.
<youpi> gnu_srs: but did your reconfigure the hurd package to remount it ?
<gnu_srs> ?
<youpi> /dev/vcs won't magically be remounted by just not being unmounted
by sysvinit
<gnu_srs> dpkg-reconfigure hurd?
<youpi> sure
<gnu_srs> I can start the console manually, but ENABLE='true' in
/etc/default/hurd-console does not work (at least with openrc)
<youpi> does /dev/vcs becomes a mere file again with openrc?
<gnu_srs> no it's a directory with 6 entries
<youpi> does the /etc/init.d/hurd-console gets to starT?
<youpi> I'm afraid I'm really asking obvious questions that you should have
already asked for yourself
<gg0> so you mounted it and it's not a file anymore. does it work now?
<gnu_srs> it seem like the service is not started, trying to figure out
why:-D
<gnu_srs> I can restart it but it is not visible in rc-status?
<gg0> shutdown stuck at "Asking all remaining processes to
terminate...done." (even before distupgrade btw)
<gg0> seems stuck at killall5 -18
<teythoon> hm, that's bad
<teythoon> how do you know that ?
<gg0> /etc/init.d/sendsigs and /etc/init.d/killprocs
<gg0> (yes, switched to sysvinit and testing openrc)
<teythoon> but killall5 -18 is SIGSTOP right?
<teythoon> and if it says ...done. then killall5 has already been run
<teythoon> so, how do you know it hangs at killall5 ?
<gg0> teythoon: "done" is "log_action_end_msg 0" just after killall5 -15,
then we should get "Killing all remaining processes" or "All processes
ended within $seq seconds."
<gg0> Asking all remaining processes to terminate...killall5 -15 -o 956 #
SIGTERM...done.
<gg0> All processes ended within 1 seconds...done.
<gg0> shutdown properly this time
<teythoon> hm
<teythoon> fwiw, i've also encountered hangs, haven't investigated yet
<gg0> with openrc?
<teythoon> yes
<gnu_srs> Is it so that with teythoons mtab translator umount -a unmounts
all passive translators, removing the translator records??
<gnu_srs> causing pflocal (and pfinet) to disappear?
<azeem> gnu_srs: didn't he say that this is getting fixed in his latest
patchset?
<gnu_srs> yes, what about mine and gg0s currently hosed systems?
<gnu_srs> yes, but until the patch makes into the next release,**
<youpi> gnu_srs: pflocal and pfinet don't appear in mtab
<youpi> because they don't expose whole directories, just a trivial node
<youpi> so no, they won't get umounted by umount -a
<youpi> simply check the content of /proc/mounts
<gnu_srs> so how come I cannot recover my image?
<gnu_srs> and gg0 neither
<youpi> no idea, I've never tried openrc
<youpi> when daring new fields, you face new issues, that's no wonder
<gnu_srs> so this does not happen with sysv-rc?
<youpi> I haven't seen any of this kind of issue
<youpi> whether it's related to using openrc vs sysvrc, I have no idea
<youpi> but at least that's a candidate for sure
<gnu_srs> well in my case hurd bootstrap is stuck after ext2fs exec and
before init
<gnu_srs> ant reinstalling hurd via linux does not help
<youpi> you mean the hurd package?
<youpi> you can also try to reinstall the libc0.3 package
<youpi> normally it should be all that is needed for boot
<youpi> perhaps also some /dev entries
<gnu_srs> yes, the hurd package. I will try with libc0.3 tomorrow. Which
/dev entries, and how to create them manually?
<youpi> "perhaps" implies that I don't know
<youpi> you can as well just boot with an install CD, mount your disk,
chroot into it, and run dpkg-reconfigure hurd there to recreate
everything in /dv
<youpi> +e
IRC, OFTC, #debian-hurd, 2014-02-13
<youpi> pere, rleigh: which script is supposed to make /etc/mtab a symlink
to /proc/mounts already? I can't find it
<pere> youpi: see /lib/init/mount-functions.sh
IRC, freenode, #hurd, 2014-02-13
<braunr> teythoon: are the sysvinit debian packages in sid usable currently
?
<teythoon> they are
<braunr> nice
<teythoon> youpi and pere have been busy polishing it quite a bit
<braunr> teythoon: and uhm, how does one enable sysvinit in debian ? :)
<braunr> ah, found pere's blog
<teythoon> braunr: didn't you read the postinst instructions ? :p
<teythoon> update-alternatives --config runsystem
<braunr> oh right
<braunr> got lost in the noise
<braunr> very nice
<braunr> still a few glitches i see, but it does the job
<braunr> although i'm not sure i like the lack of console prompt :/
<braunr> i'll keep darnassus on the old runsystem until this is fixed
<teythoon> braunr: cp -p /usr/share/sysvinit/inittab /etc/inittab
<teythoon> and kill -HUP 1
<braunr> oh
<braunr> :)
<braunr> teythoon: thanks
<braunr> teythoon: do you know why there are three tmpfs instances after
startup (/run, and in addition, /run/shm and /run/lock) instead of one on
/run ?
<braunr> sorry for being so annoying :)
<teythoon> braunr: dunno, but that is what Debian does
<braunr> https://wiki.debian.org/ReleaseGoals/RunDirectory explains it a
bit
<teythoon> root@thinkbox ~src # uname -s; mount | grep /run
<teythoon> Linux
<teythoon> tmpfs on /run type tmpfs
(rw,nosuid,noexec,relatime,size=306952k,mode=755)
<teythoon> tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k)
<teythoon> tmpfs on /run/shm type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=613900k)
<braunr> i like this /run directory
<teythoon> yep, it's nice
<braunr> ah great, i can add ,sync=30 to fstab and it's added at boot time
:)
IRC, freenode, #hurd, 2014-02-17
<congzhang> hi, I think we should make console server separate from
hurd-console
<congzhang> if DM want start, console server need be start first
<braunr> congzhang: send patches
<congzhang> and hurd-console mark it start at the end of sysinit?
<teythoon> congzhang: i agree
<braunr> teythoon: isn't hurd-console the console server ?
<congzhang> I want to check whether it is need first
<teythoon> braunr: yes, but congzhangs point is (as i understand it) that
the backend component should be started earlier
<teythoon> then again, i know little about the hurd console
<congzhang> no, if user enable one dispaly manager, then cycle dependence
happen
<braunr> why ?
<teythoon> i believe that is a different problem, namely that our
hurd-console init script depends on $all
<teythoon> pere: ^
<congzhang> hurd-console Required-Start： $all
<braunr> ok
<braunr> yes that's a separate issue, and easier to understand
<congzhang> teythoon: if wdm Required-Start hurd-console, then insserv
can't generate the script order, right ?
<teythoon> congzhang: possibly, i don't know for sure
<congzhang> It doesn't work , and I rename to S??wdm to later one like
S20wdm
<congzhang> but insserv will regenerate the script order in /etc/rc2.d/, I
can't depend on that
<pere> congzhang: $all means after all scripts not depending on $all, and
not what the intuitive interpretation would tell you.
<pere> the current implementation order all scripts as if $all were not
present, and then move all scripts depending on $all to the last order
number+1.
<pere> because $all is misunderstood by most users, I strongly recommend to
_not_ use $all in any init.d script.
<congzhang> pere: so to make wdm to be number+more?
<pere> congzhang: make it depend on $all and be lexically sorted after
hurd-console. :)
<congzhang> wdm need start after hurd-console, if console-driver will run
when hurd-console start
<pere> not quite sure how startpar handle that case, so it might not work
the way you want anyway.
<pere> adding a dependency on hurd-console should not hurt, though. :)
<congzhang> how make it lexically sorted after hurd-console?
<pere> w is already after h in the alphabet. :)
<congzhang> that's trick!
<pere> but startpar uses the info in /etc/init.d/.depend.* (makefile style)
to order scripts, so check what the result is there too.
<braunr> congzhang: no it's not
<congzhang> that's just cache
<braunr> congzhang: ?
<congzhang> and generated from script head?
<congzhang> the right way is Adding run-time dependencies in script
<pere> congzhang: yes. insserv called from update-rc.d generate the
.depend.* files, and startpar reads the files (and ignore the headers)
when starting scripts.
<congzhang> if the script have cycle dependence, no one can help
<pere> congzhang: if there is a cycle, update-rc.d will reject the script.
<congzhang> sure, because the system current have not runable one
<congzhang> Display Manager run before hurd-console, and never successful
for X stared failed!
<pere> what is this hurd-console stuff, btw? it sound like somthing that
should be started in rcboot.d (aka rcS.d on Debian).
<congzhang> if you install wdm, you will notice that wdm start failed
<pere> should it run before sulogin when booting into single user?
<congzhang> hurd-console mix too much thins
<teythoon> pere: it's the console multiplexes that provides /dev/tty?
<congzhang> just part of that function
<teythoon> pere: it's like screen or tmux a server-client architecture
<teythoon> the x server gets keyboard and mouse events from it iirc
<pere> right. so not needed by sulogin, I guess. because if it was, it
should start in rcS.d, not rc[2-5].d/.
<congzhang> and also start /bin/console to start keyboard and mouse driver
<teythoon> /bin/console is the frontend
<pere> and if it started in rcS.d/, it would always be started before
wdm. :)
<braunr> i think it should be started in rcS.d
<congzhang> why not essential?
<pere> braunr: when I tried, it failed.
<congzhang> https://www.gnu.org/software/hurd/hurd/console.html
<congzhang> teythoon: i want to make one disk img with default DM, and face
these problem
<braunr> pere: do you have a log of the failur e?
<congzhang> teythoon: I know you are working on the hurd init system, so I
ask you for help
<pere> braunr: only the boot message: Starting Hurd console multiplexer:
hurd-console failed!
<pere> braunr: how can I learn more?
<braunr> i don't know any easy way
<braunr> try to put the system in its early state manually
<braunr> and maybe run rpctrace on the actual console command
<braunr> if that is what really fails
<congzhang> and I found that pc_kbd may have some bug? I have high
frequence of start failed if I make it start
<congzhang> but I can't located the real source of these problem
<teythoon> pere: the console logs some messages to syslog
<pere> teythoon: looked, nothing there. :(
<pere> gah, look like I broke my hurd machine. Added rpctrace to the start
of hurd-console, and now the boot just hang there, and when I interrupt
it the kernel reboot the entire machine. :(
<braunr> pere: use rpctrace manually, don't script it
<teythoon> oh yeah, seen this as well
<pere> braunr: well, no use to test it after boot when it hang during
boot...
<teythoon> it triggers an assertion in the proc server iirc
<braunr> pere: that doesn't imply you need to script it
<congzhang> pere: qemu snapshot mode will be your friend:)
<braunr> ideally, i'd run the init system automatically up to the point i
want to run my test, and make it spawn a shell, and use that shell then
<pere> congzhang: hah. real men do to take backups. but they weep a
lot. :)
<congzhang> teythoon: runsystem.sysv has work well on my machine, just some
error infomation
<teythoon> good
IRC, freenode, #hurd, 2014-02-21
<gnu_srs1> Hi, a general question: is ptrace available for GNU/Hurd?
<teythoon> yes
<gnu_srs1> tks, the openrc developers are working on process supervision
using it: good/bad? (compared to cgroups)
<teythoon> uh
<teythoon> i prefer the cgroups approach
<teythoon> but upstart also uses ptrace to keep track of the 'main' process
of an daemon
<teythoon> they use ptrace to follow a daemon that double forks
<gnu_srs1> teythoon: and regarding portability?
IRC, freenode, #hurd, 2014-02-24
<braunr> sysvinit doesn't seem to handle /etc/default/locale into
consideration
IRC, OFTC, #debian-hurd, 2014-02-25
<gg0> how about switching runsystem.sysv by default?
<youpi> now that it seems to be running fine, we could do that, yes
Required Interfaces
In the thread starting here, a message has been posted that contains the following list (no claim for completeness) of interfaces that are used in (two source code files of) systemd:
- cgroups
- namespaces
- selinux
- autofs4
- capabilities
- udev
- oom score adjust
- RLIMIT_RTTIME
- RLIMIT_RTPRIO
- ionice
- SCHED_RESET_ON_FORK
- /proc/$PID/stat
- fanotify
- inotify
- TIOCVHANGUP
- IP_TRANSPORT
- audit
- F_SETPIPE_SZ
- CLONE_xxx
- BTRFS_IOC_DEFRAG
- PR_SET_NAME
- PR_CAPBSET_DROP
- PR_SET_PDEATHSIG
- PR_GET_SECUREBITS
- /proc/$PID/comm
- /proc/$PID/cmdline
- /proc/cmdline
- numerous GNU APIs like asprintf
- SOCK CLOEXEC, O CLOEXEC
- /proc/$PID/fd
- /dev/tty0
- TIOCLINUX
- VT_ACTIVATE
- TIOCNXCL
- KDSKBMODE
- /dev/random
- /dev/char/
- openat() and friends
- /proc/$PID/root
- waitid()
- /dev/disk/by-label/
- /dev/disk/by-uuid/
- /sys/class/tty/console/active
- /sys/class/dmi/id
- /proc/$PID/cgroup
- \033[3J
- /dev/rtc
- settimeofday() and its semantics
IRC, unknown channel, 2008-05-26 and later
<paakku> In elinks/src/network/state.h, there is an assumption that values of errno are between 0 and 100000. Now looking at glibc-2.5/sysdeps/mach/hurd/bits/errno.h, I see that you're using values outside this range. Have there been problems because of this?
<youpi> eeerf
<youpi> I had never seen a program assuming that
<youpi> that sucks
<paakku> It can be fixed, but that'd require some work, so I'd like to first have a clear idea of the effects.
<youpi> fixed where ?
<paakku> in elinks
<youpi> k
<paakku> by allocating just one number from our enum connection_state for system errors, and then stashing the errno value in a separate variable.
<paakku> Anyway, if you see this cause any user-visible bugs in ELinks, please report.
<kahmalo> I mentioned here on 2008-05-26 that ELinks assumes errno values are between 0 and 100000 whereas the Hurd uses other values. I fixed this in ELinks last weekend; the most recent 0.12 and 0.13 snapshots should include the fix. If you find any remaining errno assumptions, please post to: http://bugzilla.elinks.cz/show_bug.cgi?id=1013
<kahmalo> or to one of our mailing lists.
<kahmalo> I guess the pflocal select() bug http://savannah.gnu.org/bugs/?22861 is the primary hindrance to running ELinks on the Hurd. Has any decision been made on how that will be fixed?
<terpstra> do the buildds also crash?
<youpi> sometimes
<youpi> usually when a configure scripts tries to find out how large a
command line can be
<youpi> (thus eating all memory)
bash 4.0 vs. typing C-c (SIGINT)
Will show -bash: echo: write error: (ipc/mig) wrong reply message ID unter
certain conditions.
After having noticed that this error doesn't occur if starting bash with
--norc, I isolated it to the following command in .bashrc:
case $TERM in
xterm* | rxvt*)
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"';;
esac
... and indeed:
tschwinge@flubber:~ $ echo "$TERM" -- "$PROMPT_COMMAND"
xterm -- echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"
tschwinge@flubber:~ $ ^C
-bash: echo: write error: (ipc/mig) wrong reply message ID
tschwinge@flubber:~ $ PROMPT_COMMAND=
tschwinge@flubber:~ $ ^C
tschwinge@flubber:~ $
bash-4.0$ PROMPT_COMMAND='echo >&2 -n foo\ '
foo bash-4.0$ ^C
bash-4.0$ PROMPT_COMMAND='echo >&1 -n foo\ '
foo bash-4.0$ ^C
bash: echo: write error: (ipc/mig) wrong reply message ID
bash-4.0$ PROMPT_COMMAND='/bin/echo >&1 -n foo\ '
foo bash-4.0$ ^C
bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID
So, there's something different with stdout in / after the SIGINT handler.
IRC, freenode, #hurd, 2013-01-13
Perhaps completely unrelated to the issue above, perhaps not.
<tschwinge> bash: xmalloc: ../../../bash/lib/sh/strtrans.c:60: cannot
allocate 261 bytes (323584 bytes allocated)
<tschwinge> 1.5 GiB RAM were free.
<tschwinge> This happened when I did a rever history search (C-r [...]),
and then pressed C-c.
Typing C-c (SIGINT) in a screen session (Debian package 4.0.3-14; -11 is
fine):
- shell prompt: no reaction (nothing printed)
sleep 10running:^Cprinted, but SIGINT is not sent.
Revisit this issue: Debian bug #97343 -- special handling of TIOCSCTTY
depending on __GNU__.
#ifdef linux and friends are used in quite a number of places.
All diffs are GNU/Linux vs. GNU/Hurd.
/*
* If your system supports BSD4.4's seteuid() and setegid(), define
* HAVE_SETEUID.
*/
-/* #undef HAVE_SETEUID */
+#define HAVE_SETEUID 1
TODO: check.
/*
* define HAVE_SVR4_PTYS if you have a /dev/ptmx character special
* device and support the ptsname(), grantpt(), unlockpt() functions.
*/
-#define HAVE_SVR4_PTYS 1
+/* #undef HAVE_SVR4_PTYS */
/*
* define HAVE_GETPT if you have the getpt() function.
*/
#define HAVE_GETPT 1
/*
* define HAVE_OPENPTY if your system has the openpty() call.
*/
-/* #undef HAVE_OPENPTY */
+#define HAVE_OPENPTY 1
/*
* define PTYRANGE0 and or PTYRANGE1 if you want to adapt screen
* to unusual environments. E.g. For SunOs the defaults are "qpr" and
* "0123456789abcdef". For SunOs 4.1.2
* #define PTYRANGE0 "pqrstuvwxyzPQRST"
* is recommended by Dan Jacobson.
*/
-/* #undef PTYRANGE0 */
-/* #undef PTYRANGE1 */
+#define PTYRANGE0 "pq"
+#define PTYRANGE1 "0123456789abcdefghijklmnopqrstuv"
TODO: check: HAVE_SVR4_PTYS is due to configure.in doing test -c
/dev/ptmx. But: even if we don't have that file, we still have ptsname,
grantpt, unlockpt.
gcc -c -I. -I. -g -O2 -O2 -g -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers pty.c
+pty.c: In function 'OpenPTY':
+pty.c:323: warning: implicit declaration of function 'openpty'
+pty.c: At top level:
+pty.c:75: warning: 'PtyName' defined but not used
+pty.c:86: warning: 'PtyProto' defined but not used
+pty.c:87: warning: 'TtyProto' defined but not used
TODO: check.
--- linux/osdef.h 2009-10-06 18:43:53.000000000 +0200
+++ screen-4.0.3/osdef.h 2009-10-06 18:49:49.000000000 +0200
@@ -42,13 +42,19 @@
#endif
#ifdef SYSV
+extern char *strchr __P((char *, int));
+extern char *strrchr __P((char *, int));
+extern char *memset __P((char *, int, int));
+extern int memcmp __P((char *, char *, int));
#else
#endif
#ifndef USEBCOPY
# ifdef USEMEMCPY
+extern void memcpy __P((char *, char *, int));
# else
# ifdef USEMEMMOVE
+extern void memmove __P((char *, char *, int));
# else
# endif
# endif
TODO: check.
m4 (1.4.13-1+hurd.2) unreleased; urgency=low
* Drop stack overflow (checks/stackovf) check, test-c-stack and
test-c-stack2 checks, and /dev/null/ (test-open and test-fopen) checks.
-- Samuel Thibault <samuel.thibault@ens-lyon.org> Tue, 18 Aug 2009 20:54:30 +0000
<youpi> that was a quick fix (as not having m4 makes autoconf uninstallable, which is quite a problem)
<youpi> there's probably something wrong in the stack management of the Hurd, I haven't investigated
GNU Emacs mostly does work, however there are a few issues.
diredon a directory hangs. (UseC-g C-gto break the unresponsive operation.)Configuration in
src/s/:gnu.husesbsd-common.h.gnu-kfreebsd.husesgnu-linux.h-- we probably should too.gnu-linux.hmakes a few things depend on/proc(also seeHAVE_PROCFS) -- either resort to our own ways, or enhance our procfs accordingly.sysdep.c
Got a hang when compiling GNU Emacs 23, when it was compiling
.elto.elcfiles. Looked like busy-looping inside glibc. This was not reproducible so far.Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in
ext2fson/media/datawhen resuming emacs23 build in~/tmp/emacs/emacs23-*/(dpkg-buildpackage -B -uc -nc 2>&1 | tee L). No modifications toemacs23-*so far, I think. Hangs always in the same place, it seems, and reproducible. Tarred toemacs23-23.1+1.tar.bz2(beware: empty and zero-permission files:emacs23-23.1+1/.pc/debian-site-init-el.diff/lisp/site-init.el,emacs23-23.1+1/.pc/autofiles.diff/src/config.in~). At hang-time: the rootfs is fine (syncfs -c -s /works;syncfsinvolving/media/datahangs). Plan: GDB on that ext2fs, and see what's hanging / locked.
2010-10-11
Apparently, none of the Debian emacs packages are installable at the moment.
Try to compile bzr trunk.
System (sort-of) crashed during build. Perhaps while / or shortly after
dumping src/emacs, as there was such a zero-sized file. (Log file doesn't
show anything useful.) Removed the truncated src/emacs, continued build:
[...]
Compiling /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el
Parsing *srecode-map-tmp* (LALR)...
Parsing *srecode-map-tmp* (LALR)...done
Segmentation fault
make[2]: *** [cedet/srecode/mode.elc] Error 139
make[2]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp'
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp'
make: *** [lisp] Error 2
Command line:
$ EMACSLOADPATH=/home/tschwinge/tmp/emacs/trunk/lisp LC_ALL=C /home/tschwinge/tmp/emacs/trunk.build/src/emacs -batch --no-site-file -f batch-byte-compile /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el
GDB:
Program received signal SIGSEGV, Segmentation fault.
mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343
5343 if (STRING_MARKED_P (ptr))
(gdb) bt
#0 mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343
#1 0x0818080f in Fgarbage_collect () at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:4993
#2 0x08196db3 in Ffuncall (nargs=1, args=0x23fce70) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2987
#3 0x081ce8e1 in Fbyte_code (bytestr=139696577, vector=141708997, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#4 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#5 0x08196bb3 in Ffuncall (nargs=1, args=0x23fcff0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#6 0x081ce8e1 in Fbyte_code (bytestr=139922913, vector=141583493, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#7 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#8 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd170) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#9 0x081ce8e1 in Fbyte_code (bytestr=140515737, vector=141583205, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#10 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#11 0x08196bb3 in Ffuncall (nargs=2, args=0x23fd2f0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#12 0x081ce8e1 in Fbyte_code (bytestr=139911193, vector=139312997, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#13 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#14 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#15 0x081ce8e1 in Fbyte_code (bytestr=136508105, vector=136508125, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#16 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#17 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#18 0x081ce8e1 in Fbyte_code (bytestr=136508849, vector=136508869, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#19 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#20 0x08195bff in apply_lambda (fun=136508805, args=139814646, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100
#21 0x08195ef4 in Feval (form=139814582) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412
#22 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139636697, printflag=0, unibyte=138364586, readfun=138364586,
start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734
#23 0x081bbad7 in Fload (file=140023529, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586)
at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225
#24 0x081a1357 in Frequire (feature=141037690, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694
#25 0x08196d83 in Ffuncall (nargs=2, args=0x23fdb90) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996
#26 0x081ce8e1 in Fbyte_code (bytestr=140023705, vector=141489853, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#27 0x08196304 in Feval (form=141177630) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358
#28 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=140023785, printflag=0, unibyte=138364586, readfun=138364586,
start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734
#29 0x081bbad7 in Fload (file=139743441, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586)
at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225
#30 0x081a1357 in Frequire (feature=140528330, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694
#31 0x08196d83 in Ffuncall (nargs=2, args=0x23fe030) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996
#32 0x081ce8e1 in Fbyte_code (bytestr=139743489, vector=139592949, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#33 0x08196304 in Feval (form=139785254) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358
#34 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139743569, printflag=0, unibyte=138364586, readfun=138364586,
start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734
#35 0x081bbad7 in Fload (file=139985769, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586)
at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225
#36 0x081a1357 in Frequire (feature=140528282, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694
#37 0x08196d83 in Ffuncall (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996
#38 0x0819879e in Fapply (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2453
#39 0x08196e26 in Ffuncall (nargs=3, args=0x23fe5c0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2971
#40 0x081ce8e1 in Fbyte_code (bytestr=139665665, vector=140243293, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#41 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#42 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe730) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#43 0x081ce8e1 in Fbyte_code (bytestr=139663633, vector=140113917, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#44 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#45 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe8a0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#46 0x081ce8e1 in Fbyte_code (bytestr=139651313, vector=141733317, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#47 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#48 0x08196bb3 in Ffuncall (nargs=1, args=0x23fea20) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#49 0x081961cd in Feval (form=142062606) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2324
#50 0x08198ec2 in internal_lisp_condition_case (var=139619738, bodyform=142062606, handlers=142059126) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407
#51 0x081cdb3a in Fbyte_code (bytestr=139651065, vector=138947149, maxdepth=64) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869
#52 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#53 0x08196bb3 in Ffuncall (nargs=3, args=0x23fed10) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#54 0x081ce8e1 in Fbyte_code (bytestr=139638617, vector=140190309, maxdepth=32) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#55 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#56 0x08195bff in apply_lambda (fun=141815293, args=139024998, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100
#57 0x08195ef4 in Feval (form=139025038) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412
#58 0x08198ec2 in internal_lisp_condition_case (var=138727490, bodyform=139025038, handlers=138994086) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407
#59 0x081cdb3a in Fbyte_code (bytestr=141397873, vector=139422605, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869
#60 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#61 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff150) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#62 0x081ce8e1 in Fbyte_code (bytestr=141396361, vector=138448733, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#63 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#64 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff2d0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#65 0x081ce8e1 in Fbyte_code (bytestr=136699577, vector=136699597, maxdepth=40) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#66 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#67 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#68 0x081ce8e1 in Fbyte_code (bytestr=136685793, vector=136685813, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#69 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#70 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
#71 0x081ce8e1 in Fbyte_code (bytestr=136683265, vector=136683285, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
#72 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
#73 0x08195bff in apply_lambda (fun=136683245, args=138364586, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100
#74 0x08195ef4 in Feval (form=138740766) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412
#75 0x0812dd83 in top_level_2 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1336
#76 0x081951dc in internal_condition_case (bfun=0x812dd70 <top_level_2>, handlers=138394034, hfun=0x8132020 <cmd_error>)
at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1460
#77 0x08131de5 in top_level_1 (ignore=138364586) at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1344
#78 0x081952a9 in internal_catch (tag=138392170, func=0x8131d80 <top_level_1>, arg=138364586) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1204
#79 0x08131e53 in command_loop () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1299
#80 0x0813220a in recursive_edit_1 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:929
#81 0x08132332 in Frecursive_edit () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:991
#82 0x0812727b in main (argc=<value optimized out>, argv=0x23ffad8) at /home/tschwinge/tmp/emacs/trunk/src/emacs.c:1718
Next: restarted from scratch, rebuilt without optimizations.
--prefix=$PWD.install --build=i686-pc-gnu --enable-asserts
--enable-checking=all CFLAGS=-g
$ make
[...]
Dumping under the name emacs [sits here for a long time]
$ vmstat
pagesize: 4K
size: 324M
free: 9.16M
active: 56M
inactive: 242M
wired: 17.6M
zero filled: 8.75G
reactivated: 0
pageins: 289M
pageouts: 371M
page faults: 12508128
cow faults: 1411724
memobj hit ratio: 99%
swap size: 512M
swap free: 512M
Apparently low memory, but doesn't swap out.
Uses a lot of CPU time, as observed with xm top.
Creating another screen window as user tschwinge doesn't get to the shell
prompt.
Running vmstat works in a screen window that is already open, but running
ps -Af just hangs; adding -M helps.
Perhaps the /media/data/ file system (which backs /home/) is in a inconsistent state / deadlocked?
More specifically, this does not work / does not exit:
login> syncfs -s -c /media/data/ &
[2] 10785
But this works:
login> syncfs -s -c / &
[3] 10786
login>
[3]+ Done syncfs -s -c /
Thus, the rootfs still is responsive; /media/data/ is not.
login> ps -F hurd-long -T -M -w -A &
[4] 10796
login> PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc
0 0.0 0:00.00 0:00.13
1 0.0 0:00.30 0:03.55
2 0.0 0:00.30 0:04.21
3 0.0 0:00.65 0:06.88
4 0.0 0:00.02 0:00.31
5 0.0 0:00.32 0:03.72
6 0.0 0:00.00 0:00.23
7 0.0 0:00.00 0:00.03
8 0.0 0:00.30 0:03.17
9 0.0 0:00.47 0:04.69
10 0.0 0:00.62 0:06.42
11 0.0 0:00.40 0:05.91
12 0.0 0:00.47 0:04.18
13 0.0 0:00.10 0:00.73
14 0.0 0:00.56 0:05.97
15 0.0 0:00.26 0:04.61
1 0 1 1 1 1 146M 368K 0.0 0:00.00 0:00.03 /hurd/init root=device:hd0
0 0.0 0:00.00 0:00.03
2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0
0 0.0 0:00.00 0:00.00
1 92.6 0:00.00 46:33.66
2 0.0 0:00.00 0:12.07
3 0.0 0:00.00 0:00.05
4 0.0 0:00.00 0:00.02
5 0.0 0:00.00 0:00.00
6 0.0 0:00.00 0:00.01
3 0 1 1 1 173 409M 15.7M 0.2 4:39.39 34:08.86 ext2fs -A --multiboot-command-line=root=device:hd0 --host-priv-port=1 --device-master-port=2 --
[165CM-exec-server-task=3 -T typed device:hd0
0 0.0 0:00.00 0:00.02
1 0.0 0:21.78 2:32.67
2 0.0 0:00.15 0:01.33
3 0.0 0:00.07 0:01.13
4 0.0 0:22.09 2:32.56
5 0.0 0:00.11 0:01.30
6 0.0 0:21.57 2:32.78
7 0.2 0:04.10 0:54.37
8 0.0 0:00.00 0:00.01
9 0.0 0:20.96 2:30.00
10 0.0 0:00.09 0:01.05
11 0.0 0:00.09 0:00.94
12 0.0 0:21.59 2:32.40
13 0.0 0:21.50 2:32.02
14 0.0 0:00.00 0:00.92
15 0.0 0:00.07 0:00.60
16 0.0 0:00.09 0:00.86
17 0.0 0:00.04 0:00.88
18 0.0 0:00.13 0:00.91
19 0.0 0:00.04 0:00.91
20 0.0 0:00.02 0:00.89
21 0.0 0:00.08 0:00.97
22 0.0 0:00.05 0:00.84
23 0.0 0:00.04 0:00.86
24 0.0 0:00.09 0:00.86
25 0.0 0:00.11 0:00.88
26 0.0 0:00.04 0:00.64
27 0.0 0:21.10 2:32.22
28 0.0 0:20.32 2:29.92
29 0.0 0:20.58 2:31.51
30 0.0 0:20.50 2:32.72
31 0.0 0:21.05 2:30.05
32 0.0 0:19.78 2:33.40
33 0.0 0:20.55 2:31.88
34 0.0 0:00.00 0:00.06
35 0.0 0:00.00 0:00.07
36 0.0 0:00.00 0:00.02
37 0.0 0:00.01 0:00.05
38 0.0 0:00.00 0:00.03
39 0.0 0:00.00 0:00.02
40 0.0 0:00.00 0:00.06
41 0.0 0:00.02 0:00.02
42 0.0 0:00.00 0:00.03
43 0.0 0:00.00 0:00.05
44 0.0 0:00.00 0:00.07
45 0.0 0:00.00 0:00.02
46 0.0 0:00.00 0:00.02
47 0.0 0:00.00 0:00.04
48 0.0 0:00.00 0:00.03
49 0.0 0:00.00 0:00.03
50 0.0 0:00.00 0:00.05
51 0.0 0:00.00 0:00.05
52 0.0 0:00.00 0:00.04
53 0.0 0:00.00 0:00.04
54 0.0 0:00.00 0:00.02
55 0.0 0:00.00 0:00.03
56 0.0 0:00.01 0:00.01
57 0.0 0:00.03 0:00.01
58 0.0 0:00.01 0:00.00
59 0.0 0:00.00 0:00.00
60 0.0 0:00.00 0:00.00
61 0.0 0:00.00 0:00.03
62 0.0 0:00.00 0:00.00
63 0.0 0:00.00 0:00.08
64 0.0 0:00.00 0:00.06
65 0.0 0:00.01 0:00.00
66 0.0 0:00.00 0:00.07
67 0.0 0:00.00 0:00.01
68 0.0 0:00.02 0:00.02
69 0.0 0:00.01 0:00.02
70 0.0 0:00.01 0:00.01
71 0.0 0:00.01 0:00.04
72 0.0 0:00.00 0:00.01
73 0.0 0:00.01 0:00.00
74 0.0 0:00.00 0:00.06
75 0.0 0:00.00 0:00.04
76 0.0 0:00.02 0:00.05
77 0.0 0:00.00 0:00.03
78 0.0 0:00.00 0:00.02
79 0.0 0:00.00 0:00.05
80 0.0 0:00.01 0:00.00
81 0.0 0:00.00 0:00.02
82 0.0 0:00.00 0:00.03
83 0.0 0:00.00 0:00.00
84 0.0 0:00.00 0:00.00
85 0.0 0:00.00 0:00.04
86 0.0 0:00.00 0:00.04
87 0.0 0:00.00 0:00.02
88 0.0 0:00.01 0:00.00
89 0.0 0:00.00 0:00.04
90 0.0 0:00.00 0:00.04
91 0.0 0:00.00 0:00.05
92 0.0 0:00.00 0:00.02
93 0.0 0:00.00 0:00.03
94 0.0 0:00.00 0:00.02
95 0.0 0:00.00 0:00.01
96 0.0 0:00.00 0:00.02
97 0.0 0:00.00 0:00.03
98 0.0 0:00.00 0:00.05
99 0.0 0:00.00 0:00.04
100 0.0 0:00.00 0:00.03
101 0.0 0:00.00 0:00.01
102 0.0 0:00.00 0:00.01
103 0.0 0:00.00 0:00.05
104 0.0 0:00.00 0:00.06
105 0.0 0:00.01 0:00.04
106 0.0 0:00.00 0:00.00
107 0.0 0:00.01 0:00.02
108 0.0 0:00.00 0:00.00
109 0.0 0:00.00 0:00.02
110 0.0 0:00.00 0:00.01
111 0.0 0:00.00 0:00.02
112 0.0 0:00.01 0:00.04
113 0.0 0:00.01 0:00.01
114 0.0 0:00.00 0:00.02
115 0.0 0:00.01 0:00.02
116 0.0 0:00.01 0:00.03
117 0.0 0:00.00 0:00.03
118 0.0 0:00.01 0:00.01
119 0.0 0:00.00 0:00.01
120 0.0 0:00.00 0:00.05
121 0.0 0:00.00 0:00.02
122 0.0 0:00.00 0:00.02
123 0.0 0:00.00 0:00.04
124 0.0 0:00.00 0:00.04
125 0.0 0:00.00 0:00.02
126 0.0 0:00.00 0:00.02
127 0.0 0:00.01 0:00.01
128 0.0 0:00.00 0:00.01
129 0.0 0:00.01 0:00.03
130 0.0 0:00.01 0:00.05
131 0.0 0:00.00 0:00.02
132 0.0 0:00.00 0:00.03
133 0.0 0:00.00 0:00.03
134 0.0 0:00.00 0:00.02
135 0.0 0:00.00 0:00.00
136 0.0 0:00.00 0:00.01
137 0.0 0:00.01 0:00.03
138 0.0 0:00.00 0:00.03
139 0.0 0:00.00 0:00.02
140 0.0 0:00.01 0:00.01
141 0.0 0:00.01 0:00.02
142 0.0 0:00.00 0:00.00
143 0.0 0:00.00 0:00.02
144 0.0 0:00.01 0:00.00
145 0.0 0:00.00 0:00.01
146 0.0 0:00.00 0:00.00
147 0.0 0:00.00 0:00.00
148 0.0 0:00.00 0:00.03
149 0.0 0:00.00 0:00.00
150 0.0 0:00.00 0:00.01
151 0.0 0:00.00 0:00.00
152 0.0 0:00.00 0:00.01
153 0.0 0:00.00 0:00.00
154 0.0 0:00.00 0:00.00
155 0.0 0:00.00 0:00.00
156 0.0 0:00.00 0:00.00
157 0.0 0:00.00 0:00.01
158 0.0 0:00.00 0:00.00
159 0.0 0:00.00 0:00.01
160 0.0 0:00.00 0:00.01
161 0.0 0:00.00 0:00.00
162 0.0 0:00.00 0:00.00
163 0.0 0:00.00 0:00.00
164 0.0 0:00.00 0:00.01
165 0.0 0:00.00 0:00.00
166 0.0 0:00.00 0:00.00
167 0.0 0:00.00 0:00.00
168 0.0 0:00.00 0:00.00
169 0.0 0:00.00 0:00.00
170 0.0 0:00.00 0:00.00
171 0.0 0:00.00 0:00.00
172 0.0 0:00.00 0:00.00
4 0 3 1 1 6 131M 1.32M 0.0 0:02.20 0:26.26 /hurd/exec
0 0.0 0:00.43 0:05.32
1 0.0 0:00.41 0:05.54
2 0.0 0:00.44 0:05.38
3 0.0 0:00.00 0:00.00
4 0.0 0:00.45 0:05.05
5 0.0 0:00.44 0:04.95
5 0 1 1 1 6 130M 580K 0.0 0:01.17 0:14.92 /hurd/auth
0 0.0 0:00.20 0:02.99
1 0.0 0:00.00 0:00.00
2 0.0 0:00.24 0:03.03
3 0.0 0:00.18 0:02.86
4 0.0 0:00.22 0:03.01
5 0.0 0:00.31 0:03.01
6 0 1 6 6 2 147M 1.09M 0.0 0:00.01 0:00.13 /bin/bash /libexec/runsystem root=device:hd0
0 0.0 0:00.01 0:00.13
1 0.0 0:00.00 0:00.00
7 0 3 1 1 7 130M 880K 0.1 0:00.35 0:10.10 /hurd/term /dev/console device console
0 0.0 0:00.07 0:01.15
1 0.0 0:00.00 0:00.01
2 0.0 0:00.14 0:03.10
3 0.1 0:00.10 0:01.87
4 0.0 0:00.01 0:00.50
5 0.0 0:00.00 0:01.54
6 0.0 0:00.02 0:01.91
9 0 3 1 1 19 131M 1.13M 0.0 0:05.41 1:17.29 /hurd/pflocal
0 0.0 0:00.06 0:00.48
1 0.0 0:00.00 0:00.00
2 0.0 0:00.05 0:00.48
3 0.0 0:00.78 0:09.10
4 0.0 0:00.49 0:06.13
5 0.0 0:00.56 0:07.07
6 0.0 0:00.30 0:03.41
7 0.0 0:00.47 0:05.58
8 0.0 0:00.27 0:06.00
9 0.0 0:00.04 0:00.47
10 0.0 0:00.43 0:06.17
11 0.0 0:00.70 0:09.21
12 0.0 0:00.00 0:00.04
13 0.0 0:00.59 0:10.75
14 0.0 0:00.14 0:01.86
15 0.0 0:00.04 0:01.49
16 0.0 0:00.02 0:00.76
17 0.0 0:00.22 0:05.59
18 0.0 0:00.16 0:02.62
12 0 1 12 12 6 129M 1.2M 0.0 0:00.00 0:00.06 /hurd/mach-defpager
0 0.0 0:00.00 0:00.06
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
4 0.0 0:00.00 0:00.00
5 0.0 0:00.00 0:00.00
14 0 3 1 1 3 131M 504K 0.0 0:00.00 0:00.05 /hurd/storeio hd1
0 0.0 0:00.00 0:00.05
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
18 0 3 1 1 3 131M 512K 0.0 0:00.39 0:06.71 /hurd/storeio hd0
0 0.0 0:00.13 0:01.66
1 0.0 0:00.00 0:00.00
2 0.0 0:00.25 0:05.04
19 0 3 1 1 3 131M 656K 0.0 0:00.27 0:04.89 /hurd/storeio hd2
0 0.0 0:00.10 0:01.48
1 0.0 0:00.00 0:00.00
2 0.0 0:00.16 0:03.41
21 0 3 1 1 4 130M 648K 0.0 0:00.55 0:06.94 /hurd/null
0 0.0 0:00.24 0:02.09
1 0.0 0:00.00 0:00.00
2 0.0 0:00.08 0:02.16
3 0.0 0:00.22 0:02.68
22 0 3 1 1 4 130M 820K 0.0 0:00.00 0:00.05 /hurd/procfs
0 0.0 0:00.00 0:00.04
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
71 1 1 71 71 2 146M 728K 0.0 0:00.00 0:00.03 /usr/sbin/atd
0 0.0 0:00.00 0:00.02
1 0.0 0:00.00 0:00.00
77 0 3 1 1 4 130M 896K 0.0 0:00.00 0:00.02 /hurd/streamio kmsg
0 0.0 0:00.00 0:00.02
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
117 0 1 117 117 2 146M 1.02M 0.0 0:00.00 0:00.04 /usr/sbin/cron
0 0.0 0:00.00 0:00.04
1 0.0 0:00.00 0:00.00
122 101 1 122 122 2 7.75M 1.07M 0.0 0:00.00 0:00.05 /usr/bin/dbus-daemon --system
0 0.0 0:00.00 0:00.05
1 0.0 0:00.00 0:00.00
128 0 3 1 1 4 130M 908K 0.0 0:00.00 0:00.02 /hurd/fifo
0 0.0 0:00.00 0:00.02
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
131 8 1 6 6 2 147M 880K 0.0 0:00.01 0:00.07 /usr/sbin/nullmailer-send -d
0 0.0 0:00.01 0:00.07
1 0.0 0:00.00 0:00.00
139 0 3 1 1 19 133M 2.19M 0.3 0:18.66 1:17.98 /hurd/pfinet -i eth0 -a 192.168.10.63 -g 192.168.10.1 -m 255.255.255.0
0 0.0 0:00.01 0:00.03
1 0.0 0:00.00 0:00.00
2 0.1 0:12.72 0:14.56
3 0.2 0:01.65 0:12.23
4 0.0 0:01.67 0:18.56
5 0.0 0:00.50 0:05.93
6 0.0 0:00.40 0:06.16
7 0.0 0:00.57 0:05.95
8 0.0 0:00.30 0:04.15
9 0.0 0:00.15 0:01.92
10 0.0 0:00.13 0:01.45
11 0.0 0:00.14 0:01.47
12 0.0 0:00.07 0:01.06
13 0.0 0:00.08 0:01.23
14 0.0 0:00.08 0:00.92
15 0.0 0:00.03 0:00.63
16 0.0 0:00.03 0:00.45
17 0.0 0:00.05 0:00.72
18 0.0 0:00.03 0:00.49
140 0 3 1 1 3 131M 1.16M 0.0 0:00.00 0:00.05 /hurd/storeio --no-cache time
0 0.0 0:00.00 0:00.05
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
142 0 1 142 142 2 10.5M 1.23M 0.0 0:00.00 0:00.05 /usr/sbin/sshd
0 0.0 0:00.00 0:00.05
1 0.0 0:00.00 0:00.00
157 0 3 1 1 6 130M 1M 0.0 0:00.02 0:00.01 /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
0 0.0 0:00.00 0:00.00
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
4 0.0 0:00.00 0:00.01
5 0.0 0:00.01 0:00.00
158 0 6 158 158 2 146M 824K 0.0 0:00.00 0:00.01 /libexec/runttys
0 0.0 0:00.00 0:00.01
1 0.0 0:00.00 0:00.00
159 0 3 1 1 15 133M 1.67M 0.0 0:00.01 0:00.06 /hurd/console
0 0.0 0:00.01 0:00.02
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
4 0.0 0:00.00 0:00.01
5 0.0 0:00.00 0:00.00
6 0.0 0:00.00 0:00.00
7 0.0 0:00.00 0:00.02
8 0.0 0:00.00 0:00.00
9 0.0 0:00.00 0:00.00
10 0.0 0:00.00 0:00.00
11 0.0 0:00.00 0:00.00
12 0.0 0:00.00 0:00.01
13 0.0 0:00.00 0:00.00
14 0.0 0:00.00 0:00.00
160 - 158 160 160 2 147M 1.82M 0.0 0:00.02 0:00.16 -login prompt (bash)
0 0.0 0:00.02 0:00.14
1 0.0 0:00.00 0:00.02
161 - 158 161 161 2 147M 1.78M 0.0 0:00.00 0:00.07 -login prompt (bash)
0 0.0 0:00.00 0:00.07
1 0.0 0:00.00 0:00.00
162 - 158 162 162 2 147M 1.78M 0.0 0:00.01 0:00.07 -login prompt (bash)
0 0.0 0:00.01 0:00.07
1 0.0 0:00.00 0:00.00
163 - 158 163 163 2 147M 1.78M 0.0 0:00.00 0:00.03 -login prompt (bash)
0 0.0 0:00.00 0:00.03
1 0.0 0:00.00 0:00.00
164 - 158 164 164 2 147M 1.78M 0.0 0:00.02 0:00.03 -login prompt (bash)
0 0.0 0:00.02 0:00.03
1 0.0 0:00.00 0:00.00
165 - 158 165 165 2 147M 1.78M 0.0 0:00.00 0:00.08 -login prompt (bash)
0 0.0 0:00.00 0:00.08
1 0.0 0:00.00 0:00.00
166 - 158 166 166 2 147M 1.78M 0.0 0:00.01 0:00.01 -login prompt (bash)
0 0.0 0:00.01 0:00.01
1 0.0 0:00.00 0:00.00
167 0 3 1 1 6 130M 1016K 0.0 0:00.01 0:00.11 /hurd/term /dev/tty2 hurdio /dev/vcs/2/console
0 0.0 0:00.01 0:00.06
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.01
4 0.0 0:00.00 0:00.03
5 0.0 0:00.00 0:00.00
168 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty3 hurdio /dev/vcs/3/console
0 0.0 0:00.00 0:00.02
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.01
4 0.0 0:00.00 0:00.00
5 0.0 0:00.00 0:00.01
169 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty5 hurdio /dev/vcs/5/console
0 0.0 0:00.00 0:00.00
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
4 0.0 0:00.00 0:00.04
5 0.0 0:00.00 0:00.00
170 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.05 /hurd/term /dev/tty4 hurdio /dev/vcs/4/console
0 0.0 0:00.00 0:00.04
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
4 0.0 0:00.00 0:00.01
5 0.0 0:00.00 0:00.00
171 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.01 /hurd/term /dev/tty6 hurdio /dev/vcs/6/console
0 0.0 0:00.00 0:00.01
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
4 0.0 0:00.00 0:00.00
5 0.0 0:00.00 0:00.00
172 0 3 1 1 4 130M 892K 0.0 0:00.00 0:00.01 /hurd/password
0 0.0 0:00.00 0:00.01
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
3 0.0 0:00.00 0:00.00
173 0 142 173 173 3 10.7M 3.09M 0.0 0:02.09 0:12.63 /usr/sbin/sshd -R
0 0.0 0:02.09 0:12.63
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2
0 0.0 0:00.01 0:00.03
1 0.0 0:00.00 0:00.00
2 0.0 1:34.24 6:26.66
3 0.0 0:00.04 0:00.31
4 0.0 0:00.13 0:00.47
5 0.0 0:00.05 0:00.57
6 0.0 1:36.91 6:26.41
7 0.0 0:12.98 0:34.83
8 0.0 1:37.85 6:26.20
9 0.0 1:35.07 6:17.07
10 0.0 0:00.05 0:00.50
11 0.0 0:00.04 0:00.48
12 0.0 0:00.07 0:00.55
13 0.0 0:00.03 0:00.46
14 0.0 0:00.03 0:00.42
15 0.0 0:00.06 0:00.32
16 0.0 0:00.05 0:00.56
17 0.0 0:00.05 0:00.50
18 0.0 0:00.05 0:00.48
19 0.0 0:00.03 0:00.37
20 0.0 0:00.08 0:00.48
21 0.0 0:00.01 0:00.52
22 0.0 0:00.02 0:00.44
23 0.0 0:00.02 0:00.44
24 0.0 0:00.03 0:00.31
25 0.0 0:00.05 0:00.32
26 0.0 0:00.04 0:00.37
27 0.0 0:00.00 0:00.31
28 0.0 0:00.03 0:00.23
29 0.0 0:00.05 0:00.33
30 0.0 0:00.04 0:00.31
31 0.0 0:00.01 0:00.29
32 0.0 0:00.07 0:00.27
33 0.0 0:00.05 0:00.28
34 0.0 0:00.04 0:00.23
35 0.0 0:00.04 0:00.46
36 0.0 0:00.02 0:00.31
37 0.0 0:00.02 0:00.38
38 0.0 0:00.06 0:00.29
39 0.0 0:00.03 0:00.22
40 0.0 0:00.02 0:00.28
41 0.0 0:00.03 0:00.26
42 0.0 0:00.05 0:00.39
43 0.0 0:00.06 0:00.37
44 0.0 0:00.03 0:00.36
45 0.0 0:00.04 0:00.20
46 0.0 0:00.02 0:00.28
47 0.0 0:00.01 0:00.29
48 0.0 0:00.03 0:00.23
49 0.0 0:00.04 0:00.22
50 0.0 0:00.07 0:00.25
51 0.0 0:00.00 0:00.33
52 0.0 0:00.05 0:00.49
53 0.0 0:00.02 0:00.31
54 0.0 0:00.00 0:00.27
55 0.0 0:00.06 0:00.25
56 0.0 0:00.05 0:00.35
57 0.0 0:00.01 0:00.28
58 0.0 0:00.06 0:00.25
59 0.0 0:00.05 0:00.30
60 0.0 0:00.03 0:00.36
61 0.0 0:00.04 0:00.31
62 0.0 0:00.05 0:00.18
63 0.0 0:00.02 0:00.31
64 0.0 0:00.00 0:00.27
65 0.0 0:00.02 0:00.26
66 0.0 0:00.00 0:00.31
67 0.0 0:00.00 0:00.15
68 0.0 0:00.04 0:00.32
69 0.0 0:00.04 0:00.21
70 0.0 0:00.01 0:00.31
71 0.0 0:00.05 0:00.22
72 0.0 0:00.01 0:00.28
73 0.0 0:00.04 0:00.31
74 0.0 0:00.06 0:00.20
75 0.0 0:00.04 0:00.38
76 0.0 0:00.03 0:00.37
77 0.0 0:00.06 0:00.32
78 0.0 0:00.04 0:00.22
79 0.0 0:00.04 0:00.25
80 0.0 0:00.04 0:00.29
81 0.0 0:00.07 0:00.31
82 0.0 0:00.04 0:00.27
83 0.0 0:00.04 0:00.23
84 0.0 0:00.02 0:00.37
85 0.0 0:00.03 0:00.24
86 0.0 0:00.01 0:00.29
87 0.0 0:00.03 0:00.24
88 0.0 0:00.01 0:00.31
89 0.0 0:00.03 0:00.39
90 0.0 0:00.00 0:00.30
91 0.0 0:00.03 0:00.32
92 0.0 0:00.00 0:00.24
93 0.0 0:00.03 0:00.32
94 0.0 0:00.04 0:00.30
95 0.0 0:00.00 0:00.33
96 0.0 0:00.02 0:00.24
97 0.0 0:00.01 0:00.26
98 0.0 0:00.04 0:00.33
99 0.0 0:00.03 0:00.26
100 0.0 0:00.05 0:00.29
101 0.0 0:00.05 0:00.34
102 0.0 0:00.04 0:00.38
103 0.0 0:00.00 0:00.22
104 0.0 0:00.03 0:00.38
105 0.0 0:00.01 0:00.43
106 0.0 0:00.03 0:00.37
107 0.0 0:00.05 0:00.31
108 0.0 0:00.02 0:00.31
109 0.0 0:00.00 0:00.26
110 0.0 0:00.03 0:00.27
111 0.0 0:00.03 0:00.25
112 0.0 0:00.02 0:00.30
113 0.0 0:00.05 0:00.23
114 0.0 0:00.02 0:00.32
115 0.0 0:00.02 0:00.29
116 0.0 0:00.04 0:00.22
117 0.0 0:00.04 0:00.26
118 0.0 0:00.02 0:00.36
119 0.0 0:00.03 0:00.31
120 0.0 0:00.04 0:00.26
121 0.0 0:00.05 0:00.28
122 0.0 0:00.01 0:00.27
123 0.0 0:00.03 0:00.34
124 0.0 0:00.03 0:00.36
125 0.0 0:00.02 0:00.33
126 0.0 0:00.04 0:00.36
127 0.0 0:00.00 0:00.41
128 0.0 0:00.02 0:00.33
129 0.0 0:00.07 0:00.32
130 0.0 0:00.03 0:00.29
131 0.0 0:00.00 0:00.34
132 0.0 0:00.04 0:00.28
133 0.0 0:00.04 0:00.24
134 0.0 0:00.03 0:00.35
135 0.0 0:00.04 0:00.38
136 0.0 0:00.04 0:00.37
137 0.0 0:00.04 0:00.26
138 0.0 0:00.00 0:00.26
139 0.0 0:00.06 0:00.40
140 0.0 1:23.58 6:28.86
141 0.0 0:25.74 1:55.97
142 0.0 0:00.00 0:00.00
143 0.0 0:00.00 0:00.00
144 0.0 0:00.00 0:00.00
145 0.0 0:00.00 0:00.00
146 0.0 0:00.00 0:00.00
147 0.0 0:00.00 0:00.00
148 0.0 0:00.00 0:00.00
149 0.0 0:00.00 0:00.00
150 0.0 0:00.00 0:00.00
151 0.0 0:00.00 0:00.00
152 0.0 0:00.00 0:00.00
153 0.0 0:00.00 0:00.00
154 0.0 0:00.00 0:00.00
155 0.0 0:00.00 0:00.00
156 0.0 0:00.00 0:00.00
157 0.0 0:00.00 0:00.00
158 0.0 0:00.00 0:00.00
159 0.0 0:00.00 0:00.00
160 0.0 0:00.00 0:00.00
161 0.0 0:00.00 0:00.00
162 0.0 0:00.00 0:00.00
163 0.0 0:00.00 0:00.00
164 0.0 0:00.00 0:00.00
165 0.0 0:00.00 0:00.00
166 0.0 0:00.00 0:00.00
167 0.0 0:00.00 0:00.00
168 0.0 0:00.00 0:00.00
169 0.0 0:00.00 0:00.00
170 0.0 0:00.00 0:00.00
171 0.0 0:00.00 0:00.00
172 0.0 0:00.00 0:00.00
173 0.0 0:00.00 0:00.00
174 0.0 0:00.00 0:00.00
175 0.0 0:00.00 0:00.00
176 0.0 0:00.00 0:00.00
177 0.0 0:00.00 0:00.00
178 0.0 0:00.00 0:00.00
179 0.0 0:00.00 0:00.00
180 0.0 0:00.00 0:00.00
181 0.0 0:00.00 0:00.00
182 0.0 0:00.00 0:00.00
183 0.0 0:00.00 0:00.00
184 0.0 0:00.00 0:00.00
185 0.0 0:00.00 0:00.00
186 0.0 0:00.00 0:00.00
187 0.0 0:00.00 0:00.00
188 0.0 0:00.00 0:00.00
189 0.0 0:00.00 0:00.00
190 0.0 0:00.00 0:00.00
191 0.0 0:00.00 0:00.00
192 0.0 0:00.00 0:00.00
193 0.0 0:00.00 0:00.00
194 0.0 0:00.00 0:00.00
195 0.0 0:00.00 0:00.00
196 0.0 0:00.00 0:00.00
197 0.0 0:00.00 0:00.00
198 0.0 0:00.00 0:00.00
199 0.0 0:00.00 0:00.00
200 0.0 0:00.00 0:00.00
201 0.0 0:00.00 0:00.00
202 0.0 0:00.00 0:00.00
203 0.0 0:00.00 0:00.00
204 0.0 0:00.00 0:00.00
205 0.0 0:00.00 0:00.00
206 0.0 0:00.00 0:00.00
207 0.0 0:00.00 0:00.00
208 0.0 0:00.00 0:00.00
209 0.0 0:00.00 0:00.00
210 0.0 0:00.00 0:00.00
211 0.0 0:00.00 0:00.00
212 0.0 0:00.00 0:00.00
213 0.0 0:00.00 0:00.00
214 0.0 0:00.00 0:00.00
215 0.0 0:00.00 0:00.00
216 0.0 0:00.00 0:00.00
217 0.0 0:00.00 0:00.00
218 0.0 0:00.00 0:00.00
219 0.0 0:00.00 0:00.00
220 0.0 0:00.00 0:00.00
221 0.0 0:00.00 0:00.00
222 0.0 0:00.00 0:00.00
223 0.0 0:00.00 0:00.00
224 0.0 0:00.00 0:00.00
225 0.0 0:00.00 0:00.00
226 0.0 0:00.00 0:00.00
227 0.0 0:00.00 0:00.00
228 0.0 0:00.00 0:00.00
229 0.0 0:00.00 0:00.00
230 0.0 0:00.00 0:00.00
231 0.0 0:00.00 0:00.00
232 0.0 0:00.00 0:00.00
233 0.0 0:00.00 0:00.00
234 0.0 0:00.00 0:00.00
235 0.0 0:00.00 0:00.00
236 0.0 0:00.00 0:00.00
237 0.0 0:00.00 0:00.00
238 0.0 0:00.00 0:00.00
239 0.0 0:00.00 0:00.00
240 0.0 0:00.00 0:00.00
241 0.0 0:00.00 0:00.00
242 0.0 0:00.00 0:00.00
243 0.0 0:00.00 0:00.00
244 0.0 0:00.00 0:00.00
245 0.0 0:00.00 0:00.00
246 0.0 0:00.00 0:00.00
247 0.0 0:00.00 0:00.00
248 0.0 0:00.00 0:00.00
249 0.0 0:00.00 0:00.00
250 0.0 0:00.00 0:00.00
251 0.0 0:00.00 0:00.00
252 0.0 0:00.00 0:00.00
253 0.0 0:00.00 0:00.00
254 0.0 0:00.00 0:00.00
255 0.0 0:00.00 0:00.00
256 0.0 0:00.00 0:00.00
257 0.0 0:00.00 0:00.00
258 0.0 0:00.00 0:00.00
259 0.0 0:00.00 0:00.00
260 0.0 0:00.00 0:00.00
261 0.0 0:00.00 0:00.00
262 0.0 0:00.00 0:00.00
263 0.0 0:00.00 0:00.00
264 0.0 0:00.00 0:00.00
265 0.0 0:00.00 0:00.00
266 0.0 0:00.00 0:00.00
267 0.0 0:00.00 0:00.00
268 0.0 0:00.00 0:00.00
269 0.0 0:00.00 0:00.00
270 0.0 0:00.00 0:00.00
271 0.0 0:00.00 0:00.00
272 0.0 0:00.00 0:00.00
273 0.0 0:00.00 0:00.00
274 0.0 0:00.00 0:00.00
275 0.0 0:00.00 0:00.00
276 0.0 0:00.00 0:00.00
277 0.0 0:00.00 0:00.00
278 0.0 0:00.00 0:00.00
279 0.0 0:00.00 0:00.00
280 0.0 0:00.00 0:00.00
281 0.0 0:00.00 0:00.00
282 0.0 0:00.00 0:00.00
283 0.0 0:00.00 0:00.00
284 0.0 0:00.00 0:00.00
285 0.0 0:00.00 0:00.00
286 0.0 0:00.00 0:00.00
287 0.0 0:00.00 0:00.00
288 0.0 0:00.00 0:00.00
289 0.0 0:00.00 0:00.00
290 0.0 0:00.00 0:00.00
291 0.0 0:00.00 0:00.00
292 0.0 0:00.00 0:00.00
293 0.0 0:00.00 0:00.00
294 0.0 0:00.00 0:00.00
295 0.0 0:00.00 0:00.00
296 0.0 0:00.00 0:00.00
297 0.0 0:00.00 0:00.00
298 0.0 0:00.00 0:00.00
299 0.0 0:00.00 0:00.00
300 0.0 0:00.00 0:00.00
301 0.0 0:00.00 0:00.00
302 0.0 0:00.00 0:00.00
303 0.0 0:00.00 0:00.00
304 0.0 0:00.00 0:00.00
305 0.0 0:00.00 0:00.00
306 0.0 0:00.00 0:00.00
307 0.0 0:00.00 0:00.00
308 0.0 0:00.00 0:00.00
309 0.0 0:00.00 0:00.00
310 0.0 0:00.00 0:00.00
311 0.0 0:00.00 0:00.00
312 0.0 0:00.00 0:00.00
313 0.0 0:00.00 0:00.00
314 0.0 0:00.00 0:00.00
315 0.0 0:00.00 0:00.00
316 0.0 0:00.00 0:00.00
317 0.0 0:00.00 0:00.00
318 0.0 0:00.00 0:00.00
319 0.0 0:00.00 0:00.00
320 0.0 0:00.00 0:00.00
321 0.0 0:00.00 0:00.00
322 0.0 0:00.00 0:00.00
323 0.0 0:00.00 0:00.00
324 0.0 0:00.00 0:00.00
325 0.0 0:00.00 0:00.00
326 0.0 0:00.00 0:00.00
327 0.0 0:00.00 0:00.00
328 0.0 0:00.00 0:00.00
329 0.0 0:00.00 0:00.00
330 0.0 0:00.00 0:00.00
331 0.0 0:00.00 0:00.00
332 0.0 0:00.00 0:00.00
333 0.0 0:00.00 0:00.00
334 0.0 0:00.00 0:00.00
335 0.0 0:00.00 0:00.00
336 0.0 0:00.00 0:00.00
337 0.0 0:00.00 0:00.00
338 0.0 0:00.00 0:00.00
339 0.0 0:00.00 0:00.00
340 0.0 0:00.00 0:00.00
341 0.0 0:00.00 0:00.00
342 0.0 0:00.00 0:00.00
343 0.0 0:00.00 0:00.00
344 0.0 0:00.00 0:00.00
345 0.0 0:00.00 0:00.00
346 0.0 0:00.00 0:00.00
347 0.0 0:00.00 0:00.00
348 0.0 0:00.00 0:00.00
349 0.0 0:00.00 0:00.00
350 0.0 0:00.00 0:00.00
351 0.0 0:00.00 0:00.00
352 0.0 0:00.00 0:00.00
353 0.0 0:00.00 0:00.00
354 0.0 0:00.00 0:00.00
355 0.0 0:00.00 0:00.00
356 0.0 0:00.00 0:00.00
357 0.0 0:00.00 0:00.00
358 0.0 0:00.00 0:00.00
359 0.0 0:00.00 0:00.00
360 0.0 0:00.00 0:00.00
361 0.0 0:00.00 0:00.00
362 0.0 0:00.00 0:00.00
363 0.0 0:00.00 0:00.00
364 0.0 0:00.00 0:00.00
365 0.0 0:00.00 0:00.00
366 0.0 0:00.00 0:00.00
367 0.0 0:00.00 0:00.00
368 0.0 0:00.00 0:00.00
369 0.0 0:00.00 0:00.00
370 0.0 0:00.00 0:00.00
371 0.0 0:00.00 0:00.03
372 0.0 0:00.00 0:00.00
373 0.0 0:00.00 0:00.00
374 0.0 0:00.00 0:00.00
375 0.0 0:00.00 0:00.00
376 0.0 0:00.00 0:00.00
377 0.0 0:00.00 0:00.00
378 0.0 0:00.00 0:00.00
379 0.0 0:00.00 0:00.00
380 0.0 0:00.00 0:00.00
381 0.0 0:00.00 0:00.00
382 0.0 0:00.00 0:00.00
383 0.0 0:00.00 0:00.00
384 0.0 0:00.00 0:00.00
385 0.0 0:00.00 0:00.00
386 0.0 0:00.00 0:00.00
387 0.0 0:00.00 0:00.00
388 0.0 0:00.00 0:00.00
389 0.0 0:00.00 0:00.00
390 0.0 0:00.00 0:00.00
391 0.0 0:00.00 0:00.00
392 0.0 0:00.00 0:00.00
393 0.0 0:00.00 0:00.00
394 0.0 0:00.00 0:00.00
395 0.0 0:00.00 0:00.00
396 0.0 0:00.00 0:00.00
397 0.0 0:00.00 0:00.00
398 0.0 0:00.00 0:00.00
399 0.0 0:00.00 0:00.00
400 0.0 0:00.00 0:00.00
401 0.0 0:00.00 0:00.00
402 0.0 0:00.00 0:00.00
403 0.0 0:00.00 0:00.00
404 0.0 0:00.00 0:00.00
405 0.0 0:00.00 0:00.00
406 0.0 0:00.00 0:00.00
407 0.0 0:00.00 0:00.00
408 0.0 0:00.00 0:00.00
409 0.0 0:00.00 0:00.00
410 0.0 0:00.00 0:00.00
411 0.0 0:00.00 0:00.00
412 0.0 0:00.00 0:00.00
413 0.0 0:00.00 0:00.00
414 0.0 0:00.00 0:00.00
415 0.0 0:00.00 0:00.00
416 0.0 0:00.00 0:00.00
417 0.0 0:00.00 0:00.00
418 0.0 0:00.00 0:00.00
419 0.0 0:00.00 0:00.00
420 0.0 0:00.00 0:00.00
421 0.0 0:00.00 0:00.00
422 0.0 0:00.00 0:00.00
423 0.0 0:00.00 0:00.00
424 0.0 0:00.00 0:00.00
425 0.0 0:00.00 0:00.00
426 0.0 0:00.00 0:00.00
427 0.0 0:00.00 0:00.00
428 0.0 0:00.00 0:00.00
429 0.0 0:00.00 0:00.00
430 0.0 0:00.00 0:00.00
431 0.0 0:00.00 0:00.00
432 0.0 0:00.00 0:00.00
433 0.0 0:00.00 0:00.00
434 0.0 0:00.00 0:00.00
435 0.0 0:00.00 0:00.00
436 0.0 0:00.00 0:00.00
437 0.0 0:00.00 0:00.00
438 0.0 0:00.00 0:00.00
439 0.0 0:00.00 0:00.00
440 0.0 0:00.00 0:00.00
441 0.0 0:00.00 0:00.00
442 0.0 0:00.00 0:00.00
443 0.0 0:00.00 0:00.00
444 0.0 0:00.00 0:00.00
445 0.0 0:00.00 0:00.00
446 0.0 0:00.00 0:00.00
447 0.0 0:00.00 0:00.00
448 0.0 0:00.00 0:00.00
449 0.0 0:00.00 0:00.00
450 0.0 0:00.00 0:00.00
451 0.0 0:00.00 0:00.00
452 0.0 0:00.00 0:00.00
453 0.0 0:00.00 0:00.00
454 0.0 0:00.00 0:00.00
455 0.0 0:00.00 0:00.00
456 0.0 0:00.00 0:00.00
457 0.0 0:00.00 0:00.00
458 0.0 0:00.00 0:00.00
459 0.0 0:00.00 0:00.00
460 0.0 0:00.00 0:00.00
461 0.0 0:00.00 0:00.00
462 0.0 0:00.00 0:00.00
463 0.0 0:00.00 0:00.00
464 0.0 0:00.00 0:00.00
465 0.0 0:00.00 0:00.00
466 0.0 0:00.00 0:00.00
467 0.0 0:00.00 0:00.00
468 0.0 0:00.00 0:00.00
469 0.0 0:00.00 0:00.00
470 0.0 0:00.00 0:00.00
471 0.0 0:00.00 0:00.00
472 0.0 0:00.00 0:00.00
473 0.0 0:00.00 0:00.00
474 0.0 0:00.00 0:00.00
475 0.0 0:00.00 0:00.00
476 0.0 0:00.00 0:00.00
477 0.0 0:00.00 0:00.00
478 0.0 0:00.00 0:00.00
479 0.0 0:00.00 0:00.00
480 0.0 0:00.00 0:00.00
481 0.0 0:00.00 0:00.00
482 0.0 0:00.00 0:00.00
483 0.0 0:00.00 0:00.00
484 0.0 0:00.00 0:00.00
485 0.0 0:00.00 0:00.00
486 0.0 0:00.00 0:00.00
487 0.0 0:00.00 0:00.00
488 0.0 0:00.00 0:00.00
489 0.0 0:00.00 0:00.00
490 0.0 0:00.00 0:00.00
491 0.0 0:00.00 0:00.00
492 0.0 0:00.00 0:00.00
493 0.0 0:00.00 0:00.00
494 0.0 0:00.00 0:00.00
495 0.0 0:00.00 0:00.00
496 0.0 0:00.00 0:00.00
497 0.0 0:00.00 0:00.00
498 0.0 0:00.00 0:00.00
499 0.0 0:00.00 0:00.00
500 0.0 0:00.00 0:00.00
501 0.0 0:00.00 0:00.00
502 0.0 0:00.00 0:00.00
503 0.0 0:00.00 0:00.00
504 0.0 0:00.00 0:00.00
505 0.0 0:00.00 0:00.00
506 0.0 0:00.00 0:00.00
507 0.0 0:00.00 0:00.00
508 0.0 0:00.00 0:00.00
509 0.0 0:00.00 0:00.00
510 0.0 0:00.00 0:00.00
511 0.0 0:00.00 0:00.00
512 0.0 0:00.00 0:00.00
513 0.0 0:00.00 0:00.00
514 0.0 0:00.00 0:00.00
515 0.0 0:00.00 0:00.00
516 0.0 0:00.00 0:00.00
517 0.0 0:00.00 0:00.00
518 0.0 0:00.00 0:00.00
519 0.0 0:00.00 0:00.00
520 0.0 0:00.00 0:00.00
521 0.0 0:00.00 0:00.00
522 0.0 0:00.00 0:00.00
523 0.0 0:00.00 0:00.00
524 0.0 0:00.00 0:00.00
525 0.0 0:00.00 0:00.00
526 0.0 0:00.00 0:00.00
527 0.0 0:00.00 0:00.00
528 0.0 0:00.00 0:00.00
529 0.0 0:00.00 0:00.00
530 0.0 0:00.00 0:00.00
531 0.0 0:00.00 0:00.00
532 0.0 0:00.00 0:00.00
533 0.0 0:00.00 0:00.00
534 0.0 0:00.00 0:00.00
535 0.0 0:00.00 0:00.00
536 0.0 0:00.00 0:00.00
537 0.0 0:00.00 0:00.00
538 0.0 0:00.00 0:00.00
539 0.0 0:00.00 0:00.00
540 0.0 0:00.00 0:00.00
541 0.0 0:00.00 0:00.00
542 0.0 0:00.00 0:00.00
543 0.0 0:00.00 0:00.00
544 0.0 0:00.00 0:00.00
545 0.0 0:00.00 0:00.00
546 0.0 0:00.00 0:00.00
547 0.0 0:00.00 0:00.00
548 0.0 0:00.00 0:00.00
549 0.0 0:00.00 0:00.00
550 0.0 0:00.00 0:00.00
551 0.0 0:00.00 0:00.00
552 0.0 0:00.00 0:00.00
553 0.0 0:00.00 0:00.00
554 0.0 0:00.00 0:00.00
555 0.0 0:00.00 0:00.00
556 0.0 0:00.00 0:00.00
557 0.0 0:00.00 0:00.00
558 0.0 0:00.00 0:00.00
559 0.0 0:00.00 0:00.00
560 0.0 0:00.00 0:00.00
561 0.0 0:00.00 0:00.00
562 0.0 0:00.00 0:00.00
563 0.0 0:00.00 0:00.00
564 0.0 0:00.00 0:00.00
565 0.0 0:00.00 0:00.00
566 0.0 0:00.00 0:00.00
567 0.0 0:00.00 0:00.00
568 0.0 0:00.00 0:00.00
569 0.0 0:00.00 0:00.00
570 0.0 0:00.00 0:00.00
571 0.0 0:00.00 0:00.00
572 0.0 0:00.00 0:00.00
573 0.0 0:00.00 0:00.00
574 0.0 0:00.00 0:00.00
575 0.0 0:00.00 0:00.00
576 0.0 0:00.00 0:00.00
577 0.0 0:00.00 0:00.00
578 0.0 0:00.00 0:00.00
579 0.0 0:00.00 0:00.00
580 0.0 0:00.00 0:00.00
581 0.0 0:00.00 0:00.00
582 0.0 0:00.00 0:00.00
583 0.0 0:00.00 0:00.00
584 0.0 0:00.00 0:00.00
585 0.0 0:00.00 0:00.00
586 0.0 0:00.00 0:00.00
587 0.0 0:00.00 0:00.00
588 0.0 0:00.00 0:00.00
589 0.0 0:00.00 0:00.00
590 0.0 0:00.00 0:00.00
591 0.0 0:00.00 0:00.00
592 0.0 0:00.00 0:00.00
593 0.0 0:00.00 0:00.00
594 0.0 0:00.00 0:00.00
595 0.0 0:00.00 0:00.00
596 0.0 0:00.00 0:00.00
597 0.0 0:00.00 0:00.00
598 0.0 0:00.00 0:00.00
599 0.0 0:00.00 0:00.00
600 0.0 0:00.00 0:00.00
601 0.0 0:00.00 0:00.00
602 0.0 0:00.00 0:00.00
603 0.0 0:00.00 0:00.00
604 0.0 0:00.00 0:00.00
605 0.0 0:00.00 0:00.00
606 0.0 0:00.00 0:00.00
607 0.0 0:00.00 0:00.00
608 0.0 0:00.00 0:00.00
609 0.0 0:00.00 0:00.00
610 0.0 0:00.00 0:00.00
611 0.0 0:00.00 0:00.00
612 0.0 0:00.00 0:00.00
613 0.0 0:00.00 0:00.00
614 0.0 0:00.00 0:00.00
615 0.0 0:00.00 0:00.00
616 0.0 0:00.00 0:00.00
617 0.0 0:00.00 0:00.00
618 0.0 0:00.00 0:00.00
619 0.0 0:00.00 0:00.00
620 0.0 0:00.00 0:00.00
621 0.0 0:00.00 0:00.00
622 0.0 0:00.00 0:00.00
623 0.0 0:00.00 0:00.00
624 0.0 0:00.00 0:00.00
625 0.0 0:00.00 0:00.00
626 0.0 0:00.00 0:00.00
627 0.0 0:00.00 0:00.00
628 0.0 0:00.00 0:00.00
629 0.0 0:00.00 0:00.00
630 0.0 0:00.00 0:00.00
631 100.3 8:11.86 17:35.07
175 0 3 1 1 6 130M 1.08M 0.0 0:03.06 0:33.84 /hurd/term /dev/ptyp0 pty-master /dev/ttyp0
0 0.0 0:00.80 0:07.55
1 0.0 0:00.00 0:00.00
2 0.0 0:00.56 0:05.97
3 0.0 0:00.50 0:06.99
4 0.0 0:00.56 0:06.99
5 0.0 0:00.62 0:06.32
176 1000 173 176 176 2 148M 2.19M 0.0 0:00.08 0:00.54 -bash
0 0.0 0:00.08 0:00.47
1 0.0 0:00.00 0:00.07
284 1000 1 284 284 2 20.5M 700K 0.0 0:00.00 0:00.00 ssh-agent
0 0.0 0:00.00 0:00.00
1 0.0 0:00.00 0:00.00
302 1000 176 302 176 3 148M 1.37M 0.0 0:00.03 0:00.14 screen -S S_main
0 0.0 0:00.02 0:00.07
1 0.0 0:00.00 0:00.00
2 0.0 0:00.01 0:00.06
304 1000 302 304 304 3 148M 2.45M 0.0 0:02.86 0:13.03 SCREEN -S S_main
0 0.0 0:02.86 0:12.97
1 0.0 0:00.00 0:00.03
2 0.0 0:00.00 0:00.02
305 1000 3 1 1 5 130M 960K 0.0 0:01.57 0:15.62 /hurd/fifo
0 0.0 0:00.31 0:04.04
1 0.0 0:00.00 0:00.00
2 0.0 0:00.31 0:03.95
3 0.0 0:00.45 0:03.78
4 0.0 0:00.49 0:03.84
306 0 3 1 1 5 130M 1.02M 0.0 0:01.42 0:16.72 /hurd/term /dev/ptyp1 pty-master /dev/ttyp1
0 0.0 0:00.43 0:06.13
1 0.0 0:00.00 0:00.00
2 0.0 0:00.40 0:04.77
3 0.0 0:00.00 0:00.14
4 0.0 0:00.59 0:05.67
309 1000 304 309 309 2 148M 2.12M 0.0 0:00.02 0:00.09 /bin/bash
0 0.0 0:00.02 0:00.09
1 0.0 0:00.00 0:00.00
319 1000 309 319 309 2 153M 7.29M 0.0 0:00.33 0:00.74 emacs
0 0.0 0:00.33 0:00.74
1 0.0 0:00.00 0:00.00
320 0 3 1 1 6 130M 1.48M 0.0 0:03.25 0:38.79 /hurd/term /dev/ptyp2 pty-master /dev/ttyp2
0 0.0 0:00.60 0:07.07
1 0.0 0:00.00 0:00.00
2 0.0 0:00.69 0:08.43
3 0.0 0:00.78 0:07.78
4 0.0 0:00.55 0:07.98
5 0.0 0:00.60 0:07.52
323 1000 304 323 323 2 148M 2.19M 0.0 0:00.12 0:00.60 /bin/bash
0 0.0 0:00.12 0:00.54
1 0.0 0:00.00 0:00.06
411 0 3 1 1 5 130M 1.02M 0.0 0:01.17 0:16.40 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3
0 0.0 0:00.42 0:03.74
1 0.0 0:00.00 0:00.00
2 0.0 0:00.15 0:02.70
3 0.0 0:00.24 0:05.48
4 0.0 0:00.33 0:04.45
414 1000 304 414 414 2 148M 2.13M 0.0 0:00.05 0:00.23 /bin/bash
0 0.0 0:00.04 0:00.21
1 0.0 0:00.00 0:00.02
425 0 3 1 1 3 130M 872K 0.0 0:00.02 0:00.05 /hurd/proxy-defpager
0 0.0 0:00.02 0:00.04
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.01
3087 0 3 1 1 5 130M 1.02M 0.0 0:00.23 0:01.39 /hurd/term /dev/ptyp4 pty-master /dev/ttyp4
0 0.0 0:00.05 0:00.39
1 0.0 0:00.00 0:00.00
2 0.0 0:00.07 0:00.43
3 0.0 0:00.07 0:00.31
4 0.0 0:00.04 0:00.26
3648 0 3 1 1 3 130M 876K 0.0 0:00.00 0:00.05 /hurd/crash --kill
0 0.0 0:00.00 0:00.05
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
5512 0 3 1 1 5 130M 1.01M 0.0 0:00.05 0:00.70 /hurd/term /dev/ptyp5 pty-master /dev/ttyp5
0 0.0 0:00.00 0:00.26
1 0.0 0:00.00 0:00.00
2 0.0 0:00.03 0:00.16
3 0.0 0:00.02 0:00.14
4 0.0 0:00.00 0:00.14
10286 1000 323 10286 323 2 135M 1.28M 0.0 0:00.06 0:00.20 make
0 0.0 0:00.06 0:00.20
1 0.0 0:00.00 0:00.00
10287 1000 323 10286 323 2 147M 884K 0.0 0:00.00 0:00.33 tee standard output L_ LC_PAPER=en_US.utf8 LC_ADDRESS=en_US.utf8 SSH_AGENT_PID=284 LC_MONETARY=
[165CM=en_US.utf8 SP_REPLACE_LINKS=n SHELL=/bin/bash TERM=screen SP_STOP_AFTER=build HISTSIZE=10000 SSH_CLIENT=192.168.10.60 55972 22 LC_NUMERIC=en_US.utf8 OLDPWD=/home/tsch
[165CMhwinge SSH_TTY=/dev/ttyp0 USER=tschwinge HISTFILESIZE=10000 LD_LIBRARY_PATH= LC_TELEPHONE=en_US.utf8 SP_COMPAT=n LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;
[165CM;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=0
[165CM01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:
[165CM:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35
[165CM5:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=0
[165CM01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm
[165CMm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.an
[165CMnx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.
[165CM.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: SSH_AUTH_SOCK=/home/tschwinge/.ssh/auth_sock.grubber.bddebian.com TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal
[165CMl:\^K^J:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\^K^J:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\^K^J:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH
[165CMH:up=\EM:\^K^J:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\^K^J:li#50:co#166:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\^K^J:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E
[165CME[P:DC=\E[%dP:\^K^J:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\^K^J:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\^K^J:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E
[165CME[24m:so=\E[3m:\^K^J:se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\^K^J:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\^K^J:vb=\Eg:G0:as=\E(0:ae=\E(B:\^K^J:ac=\1
[165CM140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\^K^J:po=\E[5i:pf=\E[4i:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:\^K^J:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E
[165CME[18~:k8=\E[19~:\^K^J:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[1;2P:\^K^J:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:F7=\E[15;2~:\^K^J:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:k
[165CMkb=\177:K2=\EOE:\^K^J:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:*7=\E[1;2F:\^K^J:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:\^K^J:%i=\E[1;2C:kh=\E[1~:@1=\E[
[165CM[1~:kH=\E[4~:@7=\E[4~:\^K^J:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\^K^J:kr=\EOC:kl=\EOD:km: have_bash_profile=y SPF_SOURCE_DEBUG=y PATH=/home/tschwinge/c
[165CMcommand:/home/tschwinge/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games MAIL=/var/mail/tschwinge LC_MESSAGES=en_US.utf8 SP_TARDIR=/
[165CM/home/tschwinge/tmp/source/package STY=304.S_main LC_COLLATE=C LC_IDENTIFICATION=en_US.utf8 SP_FOREIGN_DIR=/home/tschwinge/shared.old/package/host/schwinge.homeip.net/
[165CM/sp-foreign-snippets/snippets PWD=/home/tschwinge/tmp/emacs/trunk.build _LD_LIBRARY_PATH= EDITOR=emacsclient LANG=en_US.utf8 TZ=Europe/Berlin LC_MEASUREMENT=en_US.utf
[165CMf8 KRB5CCNAME=/tmp/krb5cc.tschwinge HISTCONTROL=ignoreboth HOME=/home/tschwinge SHLVL=2 SPF_COMPAT=n LOGNAME=tschwinge LESS=-M -R CVS_RSH=ssh WINDOW=1 SSH_CONNECTION=1
[165CM192.168.10.60 55972 192.168.10.63 22 LC_CTYPE=en_US.utf8 LESSOPEN=| /usr/bin/lesspipe %s EMAIL=thomas@schwinge.name ALTERNATE_EDITOR=joe LC_TIME=en_US.utf8 LESSCLOSE=/
[165CM/usr/bin/lesspipe %s %s SPF_SOURCE_DATA_DIR=/home/tschwinge/shared.old/source/package/misc/spf LC_NAME=en_US.utf8 _=/usr/bin/tee
0 0.0 0:00.00 0:00.33
1 0.0 0:00.00 0:00.00
10377 1000 10286 10286 323 2 146M 828K 0.0 0:00.00 0:00.00 /bin/sh -c boot=bootstrap-emacs; \^Kif [ ! -x "src/$boot" ]; then
[165CM \^K cd src; make all \^K CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1' \^K LDFLA
[165CMAGS='-Wl,-znocombreloc ' MAKE='make' BOOTSTRAPEMACS="$boot"; \^Kfi;
0 0.0 0:00.00 0:00.00
1 0.0 0:00.00 0:00.00
10378 1000 10377 10286 323 2 135M 1.65M 0.0 0:00.71 0:02.12 make all CC=gcc CFLAGS=-g CPPFLAGS=-DXASSERTS=1 LDFLAGS=-Wl,-znocombreloc MAKE=make BOOTSTRAPE
[165CMEMACS=bootstrap-emacs
0 0.0 0:00.71 0:01.92
1 0.0 0:00.00 0:00.19
10770 1000 10378 10286 323 2 146M 852K 0.0 0:00.00 0:00.03 /bin/sh -c if test "no" = "yes"; then \^K ln -f temacs bootstrap-emacs; \^Kelse \^K `/bin/pwd
[165CMd`/temacs --batch --load loadup bootstrap || exit 1; \^K mv -f emacs bootstrap-emacs; \^Kfi
0 0.0 0:00.00 0:00.03
1 0.0 0:00.00 0:00.00
10772 1000 10770 10286 323 3 180M 38.8M 0.0 1:16.35 0:05.27 /media/data/home/tschwinge/tmp/emacs/trunk.build/src/temacs --batch --load loadup bootstrap
0 0.0 1:16.35 0:05.27
1 0.0 0:00.00 0:00.00
2 0.0 0:00.00 0:00.00
10778 1000 304 304 304 2 148M 396K 0.0 0:00.00 0:00.00 SCREEN -S S_main
0 0.0 0:00.00 0:00.00
1 0.0 0:00.00 0:00.00
10784 - 160 10784 160 2 146M 672K 0.0 0:00.00 0:00.01 syncfs -s
0 0.0 0:00.00 0:00.01
1 0.0 0:00.00 0:00.00
10785 - 160 10785 160 2 146M 672K 0.0 0:00.00 0:00.02 syncfs -s -c /media/data/
0 0.0 0:00.00 0:00.02
1 0.0 0:00.00 0:00.00
10787 0 160 10787 160 2 146M 876K 0.0 0:00.00 0:00.06 ps -Af
0 0.0 0:00.00 0:00.06
1 0.0 0:00.00 0:00.00
10795 8 131 6 6 2 147M 1.38M 0.1 0:00.02 0:00.04 /usr/lib/nullmailer/qmqp -d -s mail.schwinge.homeip.net
0 0.1 0:00.02 0:00.04
1 0.0 0:00.00 0:00.00
10796 0 160 10796 160 2 146M 1.23M 0.0 0:00.00 0:00.08 ps -F hurd-long -T -M -w -A
0 0.0 0:00.00 0:00.03
1 0.0 0:00.00 0:00.00
[4]+ Done ps -F hurd-long -T -M -w -A
login>
TH# 631 of PID 174 (which is indeed ext2fs for /media/data) looks very suspicious, likely together in combination with TH# 1 of PID 2 (GNU Mach), so likely some IPC ping-pong?
PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc
[...]
2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0
0 0.0 0:00.00 0:00.00
1 92.6 0:00.00 46:33.66
2 0.0 0:00.00 0:12.07
3 0.0 0:00.00 0:00.05
4 0.0 0:00.00 0:00.02
5 0.0 0:00.00 0:00.00
6 0.0 0:00.00 0:00.01
[...]
174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2
0 0.0 0:00.01 0:00.03
1 0.0 0:00.00 0:00.00
2 0.0 1:34.24 6:26.66
3 0.0 0:00.04 0:00.31
[...]
630 0.0 0:00.00 0:00.00
631 100.3 8:11.86 17:35.07
[...]
Attaching GDB hangs. Should have used noninvasive mode...
Having a look again after an hour or two, GNU Mach's thread 1's (system) time count has gone up to nearly 120 minutes, and ext2fs' thread 631's is up to 12 minutes user and 26 minutes system time.
I was able to get another root shell via plain ssh root@grubber, and I'm able
to attach GDB in noninvasive mode. Hopefully the first unsuccessful (but still
running) GDB didn't cause any interference.
Due to differences in thread numbering of ps and gdb, GDB's thread 632
(which is the last one anyways) should be the offending one. GDB's thread 631
and earlier ones (manually checked down to 600) are sitting in mach_msg_trap.
(gdb) thread apply 632 bt
Thread 632 (Thread 174.632):
#0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2
#1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0)
at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54
#2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397
#3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724
#4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341
#5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72
#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109
#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136
#8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300
#9 0x00000000 in ?? ()
(gdb) thread apply 632 bt full
Thread 632 (Thread 174.632):
#0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2
No locals.
#1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0)
at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54
err = <value optimized out>
#2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397
base = 321454080
#3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724
child = 0x83774a8
n = <value optimized out>
#4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341
t = 0x8377430
#5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72
status = <value optimized out>
pi = 0x0
link = {thread = 2050, next = 0x0, prevp = 0x2000, notifies = 0x12, interrupted_next = 0x0}
__PRETTY_FUNCTION__ = "internal_demuxer"
lock = -1073758644
nreqthreads = -1073750240
totalthreads = 137852072
bucket = 0x10b1c64
demuxer = 0x10b01eb <alloc_stack+11>
#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109
request = 0xbfffdf20
reply = 0xbfffbf10
mr = 3
__PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136
timeout = 0
err = <value optimized out>
hook = 0
global_timeout = 0
thread_timeout = 0
bucket = 0x805f6c0
lock = 0
totalthreads = 497
nreqthreads = 1
#8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300
t = 0x8376bd8
#9 0x00000000 in ?? ()
No symbol table info available.
May this simply be an out-of-memory situation where Mach won't / can't satisfy libports / libthreads demand? (Looks like the latter library is currently creating a new thread.) If yes, should the code be prepared for that? Is it perhaps prepared (I did not yet have a look), and re-tries again and again? Why doesn't Mach page out some pages to make memory available?
This is stock GNU Mach from Git, no patches, configured for Xen domU usage.
IRC, freenode, #hurd, 2013-10-04
<pinotree> given you are an emacs user: could you please pick the build
patch from deb#725099, recompile emacs24 and test it with your daily
work?
IRC, freenode, #hurd, 2013-10-07
<gnu_srs> Wow! emacs24 runs in X:-D
<gnu_srs> pinotree: I've now built and installed emacs 24.3. So far so good
^
<pinotree> good, keep testing and stressing
syncfs is a tiny wrapper around the file syncfs
RPC.
Its functionality should me merged into GNU coreutils' sync program, see
GNU Savannah task #6614.
There is a FOSS Factory bounty (p270) on this task.
time
Neither the time executable from the GNU time package work completely
correctly, nor does the GNU Bash built-in one.
tschwinge@flubber:~ $ \time sleep 2
0.00user 0.00system 9:38:00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ \time sleep 4
0.00user 0.00system 18:50:25elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ \time sleep 6
0.00user 0.00system 28:00:53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ time sleep 2
real 0m2.093s
user 0m0.000s
sys 0m0.011s
tschwinge@flubber:~ $ time sleep 4
real 0m4.083s
user 0m0.000s
sys 0m0.010s
tschwinge@flubber:~ $ time sleep 6
real 0m6.164s
user 0m0.000s
sys 0m0.010s
GNU time's elapsed value is off by some factor.
$ \time factor 1111111111111111111
1111111111111111111: 1111111111111111111
0.00user 0.00system 52:39:24elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
$ time factor 1111111111111111111
1111111111111111111: 1111111111111111111
real 0m11.424s
user 0m0.000s
sys 0m0.010s
As above; also here all the running time should be attributed to user time. This is probably a open issue gnumach.
2011-09-02
Might want to revisit this, and take Xen into account -- I believe flubber has already been Xenified at that time.
IRC, freenode, #hurd, 2011-09-02
While testing some IPC virtual copy performance issues:
<tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k
running, a parallel sleep 10 takes about 20 s (on strauss).
2013-03-30/31
Investigating time's configure, a difference of the output between Linux and
Hurd shows:
-checking for wait3 that fills in rusage... yes
+checking for wait3 that fills in rusage... no
This causes a different code path in resuse.c to be used; such code path does
not get a define for HZ, which is then defined with a fallback value of 60.
Debian bug #704283 has been filed with a fix for this no-wait3 case.
times
guile
IRC, freenode, #hurd, 2013-08-21
<nalaginrut> does guile2 on hurd fixed? times issue
<teythoon> nalaginrut: does not look good
<teythoon> scheme@(guile-user)> (times)
<teythoon> $1 = #(0 0 0 0 0)
<nalaginrut> well, seems not a fixed version, if there's fixed version
<nalaginrut> since it's not Guile's bug, I can do nothing for it
<teythoon> ah
<nalaginrut> in spite of this, Guile2 works I think
<nalaginrut> all tests passed but 2 fail
<nalaginrut> one of the failure is version shows "UNKNOWN" which is
trivials
<teythoon> well, did you try to fix the times issue in Hurd?
<nalaginrut> I didn't , I have to get more familiar with hurd first
<nalaginrut> I'm playing hurd these days
<teythoon> :)
<nalaginrut> anyway, I think times issue is beyond my ability at present
<nalaginrut> ;-P
<teythoon> times is implemented in the glibc, in sysdeps/mach/hurd/times.c
<teythoon> don't say that before you had a look
<nalaginrut> yes, you're right
<nalaginrut> but I think times has something to do with the kernel time
mechanism, dunno if it's related to the issue
<nalaginrut> how did you get the times.c under hurd?
<nalaginrut> apt-get source glibc?
<teythoon> well, I'd clone git://sourceware.org/git/glibc.git
<teythoon> and yes, the kernel is involved
<teythoon> task_info is used to obtain the actual values
<teythoon>
http://www.gnu.org/software/hurd/gnumach-doc/Task-Information.html
<teythoon> I'd guess that something fails, but the times(2) interface is
not able to communicate the exact failure
<nalaginrut> maybe it's not proper to get src from upstream git? since it's
OK under Linux which uses it too
<nalaginrut> but apt-get source glibc has nothing
<teythoon> so I would copy the times(2) implementation from the libc so
that you can modify it and run it as a standalone program
<teythoon> well, the libc has system dependent stuff, times(2) on Linux is
different from the Hurd version
<teythoon> it has to be
<nalaginrut> alright, I got what you mean ;-)
<teythoon> and the debian libc is built from the eglibc sources, so the
source package is called eglibc iirc
<nalaginrut> ah~I'll try
<teythoon> have you tried to rpctrace your times test program? the small c
snippet you posted the other day?
<nalaginrut> I haven't build all the tools & debug environment on my hurd
;-(
<teythoon> what tools?
<nalaginrut> well, I don't even have git on it, and I'm installing but
speed is slow, I'm looking for a new mirror
<teythoon> ah well, no need to do all this on the Hurd directly
<teythoon> building the libc takes like ages anyway
<nalaginrut> oops ;-)
<nalaginrut> I'll take your advice to concentrate on times.c only
<teythoon> oh well, it might be difficult after all, not sure though
<teythoon> times sends two task_info messages, once with TASK_BASIC_INFO,
once with TASK_THREAD_TIMES_INFO
<teythoon> here is the relevant rpctrace of your test program:
<teythoon> task131(pid14726)->task_info (1 10) = 0 {0 25 153427968 643072 0
0 0 0 1377065590 570000}
<teythoon> task131(pid14726)->task_info (3 4) = 0 {0 0 0 10000}
<teythoon> ok, I don't know enough about that to be honest, but
TASK_THREAD_TIMES_INFO behaves funny
<teythoon> I put a sleep(1) into your test program, and if I rpctrace it,
it behaves differently o_O
* nalaginrut is reading task-information page to get what it could be
<nalaginrut> maybe I have to do the same steps under Linux to find some
clue
<teythoon> no, this is Mach specific, there is no such thing on Linux
<teythoon> on Linux, times(2) is a system call
<teythoon> on Hurd, times is a function implemented in the libc that
behaves roughly the same way
<nalaginrut> OK~so different
<teythoon> look at struct task_basic_info and struct task_thread_times_info
in the task-information page for the meaning of the values in the
rpctrace
<teythoon> yes, very
<braunr> nalaginrut: you may want to try a patch i did but which is still
waiting to be merged in glibc
<nalaginrut> braunr: ah~thanks for did it ;-)
<nalaginrut> can I have the link?
<braunr> i'm getting it
<braunr> teythoon: funny things happen with rpctrace, that's expected
<braunr> keep in mind rpctrace doesn't behave like ptrace at all
<braunr> it acts as a proxy
<braunr> nalaginrut:
https://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508
<braunr> nalaginrut: you need to add it to the debian eglibc patch list,
rebuild the packages, and install the resulting .debs
<braunr> if you have trouble doing it, i'll make packages when i have time
<nalaginrut> braunr: I think your test result is expected? ;-)
<braunr> what test result ?
<nalaginrut> times test under that patch
<braunr> yes
<braunr> but i have no idea if it will work
<braunr> my patch fixes a mismatch between glibc and the procfs server
<braunr> nothing more
<braunr> it may help, it may not, that's what i'd like to know
<nalaginrut> hah~thanks for that
<nalaginrut> I get source from apt-get, then manually modified the files,
no much code ;-)
<nalaginrut> compiling
<nalaginrut> there is no cpuinfo in /proc?
<teythoon> no
<nalaginrut> a feature need to be done? or there's another way for that?
<teythoon> well, it hasn't been implemented
<teythoon> do you need that? what for?
<nalaginrut> compiling error, I realized I should use gcc-4.7
<pinotree> how are you building?
<nalaginrut> I just happened to play proc while compiling, and found
there's no
<nalaginrut> cxa_finalize.c:48:1: error: tcbhead_t has no member
named multiple_threads
<nalaginrut> I changed to gcc-4.7
<pinotree> just edit the sources, and then dpkg-buildpackage -nc -us -uc
<pinotree> that will rebuild the debian package as it would be in a debian
build, making sure all the build dependencies are there, etc
<pinotree> doing it different than that is just wrong™
<nalaginrut> ok, doing
<pinotree> were you really doing ./configure etc yourself?
<nalaginrut> well, I can't wait till it's done, I'll let it compile and
check it out tomorrow
<nalaginrut> I used configure, yes ;-P
<pinotree> not good
<nalaginrut> I have to go, thanks for help guys
IRC, freenode, #hurd, 2013-08-22
< nalaginrut> eglibc was done by dpkg-buildpackage, then how to install it?
(sorry I'm a brand new debian users)
< nalaginrut> oh~I found it
< nalaginrut> yes, (times) returns reasonable result ;-)
* nalaginrut is trying 'make check'
< nalaginrut> unfortunately, it can't pass the test though, I'm researching
it, anyway, we made first step
< nalaginrut> for Hurd internal-time-units-per-second will be 1000
< nalaginrut> , but the elapsed time is far larger than (* 2
internal-time-units-per-second)
< nalaginrut> I think the different of two returned clocks after 1 second
should be the TIME_UNITS_PER_SECOND, in principle
< nalaginrut> but I'm not sure if it's elibc or Guile bug
< nalaginrut> dunno, maybe clock tick should be 1000?
< nalaginrut> well, I'll try clock per second as 1000
< braunr> nalaginrut: clock tick (or actually, the obsolete notion of a
clock tick in userspace) should be 100
< braunr> nalaginrut: how did you come with 1000 ?
< nalaginrut> braunr: Guile set TIME_UNITS_PER_SECOND to 1000 when there's
no 8bytes size and doesn't define HAVE_CLOCK_GETTIME
< nalaginrut> #if SCM_SIZEOF_LONG >= 8 && defined HAVE_CLOCK_GETTIME
< nalaginrut> #define TIME_UNITS_PER_SECOND 1000000000
< nalaginrut> #else
< nalaginrut> #define TIME_UNITS_PER_SECOND 1000
< nalaginrut> #endif
< nalaginrut> and the test for 'times' used time-units-per-second
< pinotree> what has sizeof(long) have to do with time units per second?
< nalaginrut> dunno, maybe the representation of time?
< nalaginrut> the test failed since the difference between two clocks after
1sec is too large
< nalaginrut> and for the test context, it should small than 2 times of
units-per-second
< nalaginrut> should be smaller
< nalaginrut> sorry for bad English
< pinotree> aren't you basically looking for clock_getres?
< nalaginrut> pinotree: I don't understand what you mean
< pinotree>
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html
< nalaginrut> I wonder if there's a standard CLK_PER_SEC for Hurd
< nalaginrut> or it can be modified as wish
< pinotree> why do you need it?
< nalaginrut> the difference is 10,000,000, which can never less than
2*clock_per_second
< nalaginrut> pinotree: I don't need it, but I want to know if there's a
standard value
< braunr> nalaginrut: ok so, this is entirely a guile thing
< braunr> nalaginrut: did you test with my patch ?
< nalaginrut> braunr: yes, 'times' works fine
< braunr> but even with that, a tets fails ?
< braunr> test*
< nalaginrut> well, I can't say works fine, the proper description is "now
it has reasonable result"
< braunr> youpi: could you bring
http://git.sceen.net/hurd/glibc.git/commit/?id=90404d6d1aa01f6ce1557841f5a675bb6a30f508
into debian glibc btw ?
< nalaginrut> braunr: it failed the test since the clock run too fast, but
it should be smaller than 2*clk-per-sec
< braunr> i don't get that
< braunr> can you show the code that checks the condition ?
< nalaginrut> braunr: http://pastebin.com/sG3QxnPt
< braunr> * 0.5 internal-time-units-per-second ?
< nalaginrut> for C users, it's just like
a=times(...);sleep(1);b=times(...); then time-units-per-sec/2 <= (b-a) <=
time-units-per-sec*2
< braunr> ah ok
< nalaginrut> the test passes when it's true
< braunr> so basically, it says sleep(1) sleeps for more than 2 seconds
< braunr> can you check the actual value ?
< braunr> b-a
< nalaginrut> hold on for minutes
< nalaginrut> it's 10,000,000
< nalaginrut> for clk-per-sec=1000,000,000, it's OK
< nalaginrut> but for 100 or 1000, it's too small
< braunr> let's forget 100
< braunr> guile uses 1000
< nalaginrut> OK
< braunr> but i still don't get why
< nalaginrut> so I asked if there's standard value, or it can be ajustified
< nalaginrut> adjusted
< braunr> ok so, times are expressed in clock ticks
< braunr> are you sure you're using a patched glibc ?
< nalaginrut> yes I used your patch, and the 'times' get reasonable result
< braunr> then
< braunr> 11:28 < nalaginrut> it's 10,000,000
< braunr> doesn't make sense
< nalaginrut> hmm
< braunr> anhd i don't understand the test
< braunr> what's tms:clock new ?
< nalaginrut> it's actually the return value of 'times'
< nalaginrut> Guile wrap the clock_t and tms to a vector, then we can get
all the thing in a row
< nalaginrut> 'new' is a variable which was gotten after 1 sec
< braunr> let's see what this does exactly
< nalaginrut> equal to "new = times(...)"
< nalaginrut> 'tms' equal to (clock_t (struct tms))
< nalaginrut> we have to pass in the struct pointer to get the struct
values filled, but for Guile we don't use pointer, times actually returns
two things: clock_t and struct tms
< nalaginrut> and Guile returns them as a vector in a row, that's it
< braunr> nalaginrut: test this please:
https://darnassus.sceen.net/~rbraun/test.c
< braunr> i don't have a patched libc here
< braunr> i'll build one right now
< nalaginrut> clock ticks: 1000000
< braunr> and this seems reasonable to you ?
< braunr> anyway, i think the guile test is bugged
< nalaginrut> no, the reasonable is not for this
< braunr> does it ever get the clock tick value from sysconf() ?
< nalaginrut> I say reasonable since it's always 0 both for clock and tms,
before apply your patch
< braunr> uh no
< braunr> i have the same value, without my patch
< nalaginrut> so I said "I can't say it works fine"
< braunr> either the test is wrong because it doesn't use sysconf()
< nalaginrut> anyway, I don't think times should return "all zero"
< braunr> or the clock values have already been ocnverted
< braunr> but it doesn't
< braunr> you did something wrong
< nalaginrut> with your patch it doesn't
< braunr> without neither
< braunr> 11:43 < braunr> i have the same value, without my patch
< nalaginrut> well, it's too strange
< braunr> check how the test actually gets the clock values
< braunr> also, are your running in vbox ?
< braunr> you*
< nalaginrut> no ,it's physical machine
< braunr> oh
< braunr> nice
< braunr> note that vbox has timing issues
< nalaginrut> I thought I should give you some info of CPU, but there's no
/proc/cpuinfo
< braunr> shouldn't be needed
< nalaginrut> OK
< braunr> run my test again with an unpatched glibc
< braunr> just to make sure it produces the same result
< braunr> and
< nalaginrut> so the clock-per-sec is machine independent for Hurd I think
< braunr> 11:46 < braunr> check how the test actually gets the clock values
< nalaginrut> since it's implemented in userland
< braunr> clock-per-sec is always system dependent
< braunr> All times reported are in clock ticks.
< braunr> The number of clock ticks per second can be obtained
using:
< braunr> sysconf(_SC_CLK_TCK);
< braunr> 11:46 < braunr> check how the test actually gets the clock values
< braunr> to see if they're converted before reaching the test code or not
* nalaginrut is building eglibc
< braunr> building ?
< braunr> what for ?
< nalaginrut> I modified it to 1000, now it's useless
< braunr> we want it to 100 either way
< nalaginrut> and how to reinstall eglibc under debian?
< braunr> it's obsolete, procfs already uses 100, and 100 is low enough to
avoid overflows in practically all cases
< braunr> aptitude install libc0.3=<version>
< nalaginrut> OK
< braunr> aptitude show -v libc0.3
< braunr> for the list of available versions
< nalaginrut> out of topic, what's the meaning of the code in
quantize_timeval ?
< nalaginrut> tv->tv_usec = ((tv->tv_usec + (quantum - 1)) / quantum) *
quantum;
< nalaginrut> I can't understand this line
< braunr> scaling and rounding i guess
< nalaginrut> hmm...but quantum seems always set to 1?
< nalaginrut> 100/__getclktck()
< braunr> ah right
< braunr> old crap from the past
< nalaginrut> and clk-tck is 100
< braunr> the author probably anticipated clk_ticks could vary
< braunr> in practice it doesn't, and that's why it's been made obsolete
< nalaginrut> I wonder if it could be vary
< braunr> no
< nalaginrut> alright
< nalaginrut> why not just assign it to 1?
< braunr> 11:55 < braunr> old crap from the past
< braunr> the hurd is 20 years old
< braunr> like linux
< nalaginrut> oh~
< braunr> but with a lot less maintenance
< nalaginrut> braunr: well, I tried the original eglibc, your test was
clock ticks: 1000000
< nalaginrut> but in Guile, (times) ==> (0 0 0 0 0)
< nalaginrut> the reasonable result maybe: #(4491527510000000 80000000 0 0
0)
< braunr> 11:46 < braunr> check how the test actually gets the clock values
< braunr> ah, he left
IRC, freenode, #hurd, 2013-08-23
< braunr> nalaginrut: times() doesn't seem to be affected by my patch at
all
< nalaginrut> braunr: but it did in my machine
< nalaginrut> well, I think you mean it doesn't affect your C test code
< braunr> i'm almost sure something was wrong in your test
< braunr> keep using the official debian glibc package
< nalaginrut> I don't think it's test issue, since every time (times)
return zero, the test can never get correct result
< braunr> times doesn't return 0
< braunr> for sleep(1), i always have the right result, except in
microseconds
< nalaginrut> times in Guile always return #(0 0 0 0 0)
< braunr> (microseconds is the native mach time unit)
< braunr> well, guile does something wrong
< nalaginrut> after sleep 1, it's 0 again, so it's none sense
< braunr> 11:46 < braunr> check how the test actually gets the clock values
< braunr> not on my system
< nalaginrut> but (times) returns reasonable result after applied your
patch
< braunr> that's not normal, since times isn't affected by my patch
< nalaginrut> oops
< braunr> you need to look for what happens in guile between the times()
call and the #(0 0 0 0 0) values
< nalaginrut> well, I tried many times between patch or non-patch, I think
there's no mistake
< nalaginrut> I read the 'times' code in Guile, there's nothing strange,
just call 'times' and put all the result to a vector
< braunr> which means there is no conversion
< braunr> in which case the test is plain wrong since there MUST also be a
call to sysconf()
< braunr> to obtain the right clock ticks value
< braunr> is your box reachable with ssh ?
< nalaginrut> oh~wait, seems there's a quotient operation, I'm checking
< nalaginrut> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
< nalaginrut> scm_from_long (ticks_per_second));
< braunr> iirc, TIME_UNITS_PER_SECOND is hardcoded
< nalaginrut> unless factor is zero
< nalaginrut> yes, it's hardcoded
< braunr> that's completely non portable and wrong
< nalaginrut> you suggest to call sysconf?
< braunr> yes
< braunr> but i don't have the code in mind
< braunr> what is ticks_per_second ?
< nalaginrut> OK, that's one issue, we have to find why times return 0
< braunr> 14:14 < braunr> is your box reachable with ssh ?
< braunr> i'd like to make sure times returns 0 at your side
< braunr> because it doesn't at mine
< nalaginrut> no
< braunr> until i can reproduce, i can't consider there is a problem
< nalaginrut> I think it's unreachable for outer space
< nalaginrut> well, if you want to reproduce, just get guile src of debian
< braunr> guile 2.0 ?
< nalaginrut> yes, apt-get source guile-2.0
< nalaginrut> I'm checking ticks_per_second
< braunr> got the source, how do i test
< braunr> ?
< nalaginrut> you have to build it, and run ./meta/guile, then you don't
have to install it
< nalaginrut> and try (times)
< braunr> aw libgc
< nalaginrut> the reasonable result should be #(4313401920000000 110000000
20000000 0 0) or something alike
< nalaginrut> but #(0 0 0 0 0) in each time is not reasonable apparently
< nalaginrut> maybe you need apt-get build-dep guile-2.0?
< braunr> already done
< nalaginrut> building Guile2 may take very long time
< nalaginrut> about 30 minutes in my old machine
< braunr> then it should take just a few minutes on mine
< nalaginrut> alright it's not very long, I've spent 8 hours for gcc in LFS
< braunr> 8 hours ?
< braunr> takes 5-10 minutes on a common machine ..
< nalaginrut> but it's Celeron566 at that time...
< braunr> ah, that old
< nalaginrut> include bootstrap, so very long
< braunr> nalaginrut: i got the test failure from the build procedure, how
do i run it manually ?
< nalaginrut> braunr: ./meta/guile -L test-suite
test-suite/tests/time.test
< nalaginrut> braunr: or make check for all
< braunr> put a print after the schedule() and before the return nil; in
runtime_mstart, since that's the body of new threads
< nlightnfotis> unfortunately, I can't confirm this with goroutines
running; the assertion failure aborts before I can get anything useful
< braunr> you can
< braunr> make sure there is a \n in the message, since stdout is line
buffered by default
< braunr> if you don't reach that code, it means threads don't exit
< braunr> at least goroutine threads
< braunr> btw, where is the main thread running ?
< nlightnfotis> I just checked there is a \n at the end.
< nlightnfotis> "<braunr> btw, where is the main thread running " could you
elaborate a little bit on this?
< braunr> what does main() after initializing the runtime ?
< braunr> +do
< nlightnfotis> the runtime main or the process's main?
< braunr> the process
< braunr> nlightnfotis: what we're interested in is knowing whether main()
exits or not
< nlightnfotis> braunr: I can see there are about 4 functions of interest:
runtime_main (the main goroutine, and I can imagine 1st thread)
< nlightnfotis> main_init (I don't know what it does, will check this out
now)
< nlightnfotis> main_main (not sure about this one either)
< nlightnfotis> and runtime_exit (0)
< braunr> i can see that too
< braunr> i'm asking about main()
< nlightnfotis> which seems to be the function that terminates the main
thread
< nlightnfotis> <braunr> nlightnfotis: what we're interested in is knowing
whether main() exits or not --> my theory is runtime_exit (0) exits the
process' main. Seeing as at various times go programs echo $? == 0.
< nlightnfotis> let me research that a little bit
< nlightnfotis> braunr: that will require a bit more studying. main_main()
and main_init() are both expanded to assembly tags if I understand it
correctly.
< nlightnfotis> main.main and __go_init_main respectively.
< braunr> why are you looking from there instead of looking from main() ?
< nlightnfotis> are we not looking out if main exits?
< braunr> we are
< braunr> so why look at main_main ?
< braunr> or anything else than main ?
< nlightnfotis> these are called inside runtime_main and I figured out they
might have a clue
< braunr> runtime_main != main
< braunr> (except if there is aliasing)
< nlightnfotis> there is still the possibility that runtime_main is the
main function and that runtime_exit(0) exits it.
< braunr> there is no doubt that main is main
< braunr> (almost)
< nlightnfotis> and I just found out that there is no main in assembly
produced from go. Only main.main
< braunr> check the elf headers for the entry point then
< nlightnfotis> braunr: I went through the headers, and found the process'
main. You can find it in <gcc_root>/libgo/runtime/go-main.c
< nlightnfotis> it seems very strange though: It creates a new thread, then
aborts?
< braunr> nlightnfotis: see :)
< braunr> nlightnfotis: add traces there
< nlightnfotis> braunr: can you look into that piece of code to check out
something I don't understand?
< nlightnfotis> braunr: I can not seem able to find __go_go 's definition
< nlightnfotis> only a declaration in runtime.h
< braunr>
https://github.com/NlightNFotis/gcc/blob/master/libgo/runtime/proc.c,
line 1552
< nlightnfotis> gee thanx. For a strange kind of fashion, I was looking for
it in runtime.c
< braunr> use git grep
< braunr> or tags/cscope
< nlightnfotis> braunr: yep! runtime_exit does seem to terminate a go
process that was not otherwise abnormally terminated.
< braunr> ?
< braunr> is it called or not ?
< braunr> runtime_exit is a macro on exit()
< braunr> so we already know what it does
< nlightnfotis> it is called
< braunr> ok
< braunr> that's not normal :)
< nlightnfotis> for a simple program
< braunr> uh ?
< nlightnfotis> for one that has a go routine
< braunr> but
< nlightnfotis> it doesn't
< nlightnfotis> it's expected
< braunr> ok
< braunr> that makes sense
< braunr> well, trace
< braunr> keep tracing
< braunr> for example in main()
< braunr> is runtime_mstart() actually reached ?
< nlightnfotis> yeah main and runtime_main were my next two targets
< braunr> good
< nlightnfotis> and now I followed your advice and it does compiler much
faster
< braunr> so, it looks like the main thread just becomes a mere kernel
thread
< braunr> running runtime_mstart() and fetching goroutines as needed
< braunr> after your traces, i'd suggest running a small go test program,
with one simple goroutine (doesn't crash right ?)
< braunr> and trace context switching
< braunr> but after the traces
< braunr> one important trace is to understand why runtime_exit gets called
< nlightnfotis> it does crash even with 1 goroutine
< braunr> oh
< braunr> when doesn't it crash ?
< nlightnfotis> when it has 0 goroutines
< nlightnfotis> it works as expected
< nlightnfotis> but anything involving goroutines crashes
< nlightnfotis> and goroutines are very important; everything in the
standard library involves goroutines
< braunr> ok
< braunr> doesn't change what i suggested, good
< braunr> 1/ find out why runtime_exit gets called
< braunr> 2/ trace context switching with 1 goroutine
< nlightnfotis> on it.
< braunr> in all cases, make all your goroutines (including the main one)
*not* return
< braunr> so that you don't deal with goroutine destruction yet
< nlightnfotis> runtime_mstart in main doesn't to be run at all. So the
path is __go_go and then return from it.
< nlightnfotis> *doesn't seem
IRC, freenode, #hurd, 2013-08-26
< braunr> youpi: my glibc clock patch looks incomplete btw
< youpi> which one?
< youpi> ah, the ticks one?
< braunr> yes
< braunr> it doesn't change the values returned by times
< braunr> as a side effect, the load average bumps to 2+ on an idle machine
IRC, freenode, #hurd, 2013-08-27
< nalaginrut> braunr: have you tried Guile2 on your machine? ;-)
< braunr> nalaginrut: no
< braunr> nalaginrut: but i saw the code actually does use sysconf()
< nalaginrut> braunr: yes, for ticks_per_second
< braunr> i had to look myself to find it out, you didn't say it, despite
me asking multiple times
< braunr> it won't make debugging easier ;p
< braunr> nalaginrut: also, the return value of times is actually *never*
used
< braunr> i don't know why you've been talking about it so much
< nalaginrut> braunr: I'm sorry, it's first time to look stime.c for me
< braunr> the interesting function is get_internal_run_time_times()
< nalaginrut> what do you mean about "the return value of times is actually
*never* used"? in which context?
< braunr> see get_internal_run_time_times
< braunr> struct tms time_buffer;
< braunr> times(&time_buffer);
< braunr> return ...
< braunr> and yes, the user and system time reported in struct tms are 0
< braunr> let's see what posix has to say about it
< pinotree> it says it will return (clock_t)-1 for errors, but no standard
errors are defined yet
< nalaginrut> but I don't think get_internal_run_time_times has something
to do with scm_times
< braunr> well, i don't see any other call to times()
< braunr> i've asked you repeatedly to look for how guile fetches the data
< braunr> i think it's done in get_internal_run_time_times
< braunr> what makes you think otherwise ?
< braunr> our times() seems to behave fine, other than the units of the
return value
< nalaginrut> I don't understand what do you mean?
get_internal_run_time_times is unrelated to scm_times which is actually
"times" in Scheme code
< braunr> ok
< nalaginrut> I think we're talking about "times" activity, right?
< braunr> ok so result is a vector
< braunr> with the return value and the four values in struct tms
< nalaginrut> yes
< braunr> and what looks interesting is
< braunr> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
scm_from_long (ticks_per_second));
< braunr> SCM_SIMPLE_VECTOR_SET (result, 0, scm_product (scm_from_long
(rv), factor));
< braunr> TIME_UNITS_PER_SECOND is 1000
< nalaginrut> yes, it means (clock_t *
(TIME_UNITS_PER_SECOND/ticks_per_second)), though I've no idea why it
does this
< braunr> normalizing values i guess
< nalaginrut> I wonder if the factor should be 1, just guessing
< braunr> let's see what our clock tick really is
< braunr> 1000000 on an unmodified libc
< braunr> 100 with my patch
< nalaginrut> so what's the problem?
< nalaginrut> all the values were multiplied by ticks, it's fair for the
subtraction
< nalaginrut> I think the problem is clock is too large for the difference
between utime and utime(sleep 1)
< nalaginrut> oops, is too small
< nalaginrut> sorry, I confused,
< nalaginrut> the problem is the difference of clock is too large for
2*internal-time-units-per-second
< nalaginrut> and actually, internal-time-units-per-second is
SCM_TIME_UNITS_PER_SECOND
< nalaginrut> but without your patch, 'times' would return zeros all the
time, which is never meet the condition: SCM_TIME_UNITS_PER_SECOND/2 <=
(clock2 - clock1)
< nalaginrut> well, maybe your point is
TIME_UNITS_PER_SECOND/ticks_per_second is too small without your patch,
which causes the scm_to_long cast give a 0 value
< nalaginrut> s/cast/casting
< nalaginrut> when ticks_per_second is 100, the factor would be 10, which
seems to be reasonable
< nalaginrut> s/scm_to_long/scm_from_long
< nalaginrut> well, I have to checkout this
< nalaginrut> OK, let me reconstruct the point: ticks_per_second so too
large that makes the factor becomes zero
< nalaginrut> but decrease ticks_per_second to 100 causes the clock become
too large than TIME_UNITS_PER_SECOND
< braunr> 10:59 < nalaginrut> but without your patch, 'times' would return
zeros all the time, which is never meet the condition:
SCM_TIME_UNITS_PER_SECOND/2 <= (clock2 - clock1)
< braunr> until you prove me otherwise, this is plain wrong
< braunr> times() never returned me 0
< braunr> so let's see, this gives us a factor of 1000 / 1000000
< braunr> so the problem is factor being 0
< braunr> that's why *guile* times returns 0
< braunr> with my patch it should return 10
< nalaginrut> braunr: I'm sorry I mean "stime" in Scheme returns zeros
< nalaginrut> yes, I think the problem is factor
< nalaginrut> the factor
< braunr> now why doesn't my patch fix it all ?
< braunr> ah yes, rv is still in microseconds
< braunr> that's what i've been telling youpi recently, my patch is
incomplete
< braunr> i'll cook a quick fix, give me a few minutes please
< nalaginrut> but it fixed something ;-)
< braunr> well, guile makes a stupid assumption here
< braunr> so it's not really a fix
< nalaginrut> braunr: should I ask some info about TIME_UNITS_PER_SECOND
from Guile community?
< nalaginrut> or it doesn't help
< braunr> what do you want to ask them ?
< nalaginrut> since I don't know how this value was chosen
< nalaginrut> dunno, I'll ask if you need it
< nalaginrut> I just think maybe you need this info
< braunr> well
< braunr> my plan is to align the hurd on what other archs do
< braunr> i.e. set clk_tck to 100
< braunr> in which case this won't be a problem any more
< braunr> now you could warn them about the protability issue
< braunr> i'm not sure if they would care though
< nalaginrut> the warning is useful for the future
< nalaginrut> and it's not hard to make a change I think, for a constant,
but it depends on the maintainers
< braunr> it's not that simple
< braunr> time related things can easily overflow in the future
< nalaginrut> alright
< braunr> refer to the 2038 end-of-the-world bug
< nalaginrut> so how can I describe the warning/suggestion to them?
< braunr> i'm not sure
< braunr> tell them the TIME_UNITS_PER_SECOND isn't appropriate for larger
values of clk_tck
< braunr> dammit, microseconds are hardcoded everywhere in
sysdeps/mach/hurd ... >(
< braunr> nalaginrut: my new patch seems to fix the problem
< braunr> nalaginrut: i've built debian packages with which you can
directly test
< braunr> nalaginrut: deb http://ftp.sceen.net/debian-hurd-i386
experimental/
< braunr> Totals for this test run:
< braunr> passes: 38605
< braunr> failures: 0
< braunr> unexpected passes: 0
< braunr> expected failures: 7
< braunr> unresolved test cases: 578
< braunr> untested test cases: 1
< braunr> unsupported test cases: 10
< braunr> errors: 0
< braunr> PASS: check-guile
< braunr> =============
< braunr> 1 test passed
< braunr> =============
< braunr> :)
< braunr> youpi: the branch i added to glibc contains a working patch for
clock_t in centiseconds
< youpi> k
IRC, freenode, #hurd, 2013-08-28
<nalaginrut> braunr: well, looks great! I'll try it soon~
<nalaginrut> braunr: BTW, where is the patch/
<mark_weaver> braunr: what was needed to get guile working on the hurd?
<mark_weaver> well, if the fix wasn't to guile, I don't need the details.
<braunr> 04:53 < nalaginrut> braunr: BTW, where is the patch/
<braunr> there is hardly anyone here at 5am
<braunr> nalaginrut:
https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds
<nalaginrut> braunr: thanks for that, but why not use a constant for 100?
<braunr> nalaginrut: i don't know where to define it
<braunr> it's glibc, you don't define new stuff mindlessly
<youpi> braunr: about your centiseconds patch, did you run the libc
testsuite with it?
<mark_weaver> it does seem a shame to reduce the resolution of the timers
from microseconds to centiseconds. I wonder if that could be avoided.
<youpi> by fixing all applications which assume centiseconds
<mark_weaver> *nod* well, if there's such a problem in Guile, I'd be glad
to fix that.
<braunr> youpi: no
<mark_weaver> I see that there's a macro CLOCKS_PER_SEC that programs
should consult.
<youpi> braunr: ok, I'll do then
<braunr> mark_weaver: why is it a shame ?
<braunr> it's not clock or timer resolution
<youpi> it's clock_t resolution
<braunr> it's an obsolete api to measure average cpu usage
<braunr> having such a big value on the other hand reduces the cpu usage
durations
<mark_weaver> braunr: good point :) I confess to being mostly ignorant of
these APIs.
<mark_weaver> Though Guile should still consult CLOCKS_PER_SEC instead of
assuming centiseconds. If it's making an improper assumption, I'd like
to know so I can fix it.
<braunr> the improper assumption is that there are less than 1000 clock
ticks per second
<mark_weaver> do you know off-hand of some code in Guile that is making
improper assumptions?
<braunr> yes
<braunr> let me find it
<mark_weaver> thanks
<braunr> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
<braunr> scm_from_long (ticks_per_second));
<braunr> it seems guile attempts to normalize all times values to
TIME_UNITS_PER_SECOND
<braunr> while i think it would be better off using ticks_per_second (clock
ticks as provided by sysconf())
<braunr> attempting to normalize here causes factor to become 0 if
TIME_UNITS_PER_SECOND < ticks_per_second
<mark_weaver> ah, I see.
<mark_weaver> I'll take care of it. thanks for the pointer!
<youpi> braunr: I've commited the centisecond patch to debian's glibc
IRC, freenode, #hurd, 2013-08-29
<nalaginrut> braunr: Guile2 works smoothly now, let me try something cool
with it
<braunr> nalaginrut: nice
IRC, OFTC, #debian-hurd, 2013-09-29
<pinotree> youpi: is the latest glibc carrying the changes related to
timing? what about gb guile-2.0 with it?
<youpi> it does
<youpi> so that was the only issue with guile?
<youpi> well at least we'll see
<pinotree> iirc yes
<pinotree> according to nalaginrut and the latest build log, it'd seem so
<youpi> started
<youpi> yay, guile-2.0 :)
<pinotree> yay
adduser does work as expected, the following warnings are spurious, they just
appear when one doesn't have the nscd package. They do not appear on Linux boxes
because there posix_spawn doesn't report ENOENT for exec(). POSIX indeed says
that `if the error occurs after the calling process successfully returns, the
child process shall exit with exit status 127'. The Hurd however reports all
errors, thus the warning.
$ sudo adduser foo
Adding user `foo' ...
Adding new group `foo' (1002) ...
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
Adding new user `foo' (1002) with group `foo' ...
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
posix_spawn() error=1073741826
Creating home directory `/home/foo' ...
Copying files from `/etc/skel' ...
[...]
Reported at Debian bug #623199.
2008-12
On the otherwise-idle flubber:
$ git clone git://sources.redhat.com/git/glibc.git
Initialized empty Git repository in /media/data/home/tschwinge/tmp/glibc/glibc/.git/
remote: Generating pack...
remote: Done counting 380933 objects.
remote: Deltifying 380933 objects...
remote: 100% (380933/380933) done
remote: Total 380933 (delta 294166), reused 380686 (delta 294002)
Receiving objects: 100% (380933/380933), 70.31 MiB | 27 KiB/s, done.
Resolving deltas: 100% (294166/294166), done.
error: git-checkout-index: unable to create file iconvdata/ibm1122.c (Interrupted system call)
error: git-checkout-index: unable to create file localedata/charmaps/IBM862 (Interrupted system call)
Checking out files: 100% (10676/10676), done.
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: iconvdata/ibm1122.c
# modified: localedata/charmaps/IBM862
#
no changes added to commit (use "git add" and/or "git commit -a")
$ ls -l iconvdata/ibm1122.c localedata/charmaps/IBM862
-rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 iconvdata/ibm1122.c
-rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 localedata/charmaps/IBM862
So these files are indeed of zero-length in the checked-out tree. Is this Git's fault or something else's?
Fixing this situation is easy enough:
$ git checkout -- iconvdata/ibm1122.c localedata/charmaps/IBM862
$ git status
# On branch master
nothing to commit (working directory clean)
2010-03-16
Still seen.
IRC, freenode, #hurd, 2013-10-10
<sea`> Huh? I've cloned the 'hurd' repository and I'm attempting to compile
it, but the 'rtnetlink.h' header in
'hurd/pfinet/linux-src/include/linux/' is just blank. (Which leads to an
error later down when a macro that's supposed to be defined in there is
first used)
<sea`> So I'm just wondering, is that file really blank? Or is this some
unexpected error of decompression?
<braunr> clone again and see
<braunr> the file is definitely not empty
<sea`> I cloned it twice, both have that file blank. BUT, I want to point
out that both clones do have some decompression errors. (Some files are
missing chunks in /both/ cloned repositories).
<braunr> where did you clone it from ?
<sea`> git.sv.gnu.org/hurd/hurd.git
<braunr> hum decompression errors ?
<braunr> can you paste them please ?
<sea`> Hmm, I can clone again and show you an example if I find one
<sea`> This was on the hurd. When I run: git clone $repo;, it seems to fail
almost randomly with "incorrect header check", but when it does succeed,
occasionally some files are missing chunks
<sea`> and apparently entire files can be blank
<braunr> http or git ?
<sea`> git.
<braunr> that's really weird
<braunr> actually i don't even have problems with http any more nowadays ..
<sea`> This is using the hurd image from sthibault
<sea`> So once I get it recompiled and shuffle in the new binaries, the
problem should probably go away
<braunr> no
<braunr> well maybe but
<braunr> don't recompile
<braunr> upgrade packages instead
<sea`> Alright, I'll do an upgrade instead. Why that path specifically?
<braunr> rebuilding is long
<braunr> i wonder if the image you got is corrupted
<braunr> compute the checksum
<braunr> we've had weird reports in the past about the images he provides
<braunr> well not the images themselves, but differences after dowloading
..
<braunr> downloading*
<sea`> The MD5SUMS file on his site isn't including the values for the most
recent images.
<sea`> It stops at 2012-12-28
<braunr> hummm
<sea`> Anyway, let's see. git clone failed again:
<sea`> Receiving objects: 100% (50955/50955), 15.48 MiB | 42 KiB/s, done.
<sea`> error: inflate: date stream error (incorrect header check) <- This
is the interesting part
<sea`> fatal: serious inflate inconsistency
<sea`> fatal: index-pack failed
<braunr> not intereseting enough unfortunately
<braunr> but it might come from savannah too
<sea`> Ehm. The whole thing locked up badly. I'll reboot it and try again.
<braunr> are you sure it locked oO ?
<braunr> the hurd can easily become unresponsive when performing io
operations
<braunr> but you need more than such a git repository to reach that state
<sea`> Yeah, that happens occasionally. It's not related to git, but rather
it happens when I cancel some command.
<braunr> your image must be corrupted
<braunr> have you enabled host io caching btw ?
<sea`> By now it's corrupted for sure..everytime it crashes the filesystem
gets into a weird state.
<sea`> I'll unpack a fresh image, then update the packages, and then try
cloning this git repository.
<braunr> i'll get the image too so we can compare sums
<sea`> 957bb0768c9558564f0c3e0adb9b317e ./debian-hurd.img.tar.gz
<sea`> Which unpacks to: debian-hurd-20130504.img
<azeem_> the NSA might backdoor the Hurd, in anticipation of our scheduled
world-dominance
<braunr> for now they're doing it passively :
<braunr> :p
<braunr> sea`: same thing here
<braunr> sea`: if you still have problems, the image itself might be wrong
<braunr> in which case you should try with the debian network installer
<sea`> Ah, so if problems persist, try with the network installer. Okay
<sea`> Is there some recipe for constructing a hurd/mach minimal
environment?
<sea`> A system with only just enough tools and libraries to compile and
poke at things.
<braunr> not currently
<braunr> we all work in debian environments
<braunr> the reason being that a lot of patches are queued for integration
upstream
2010-11-17
A very similar issue. The working tree had a lot of differences to HEAD.
tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
error: unable to unlink old 'gcc/config/darwin.h' (Interrupted system call)
Checking out files: 100% (1149/1149), done.
fatal: Could not reset index file to revision 'HEAD'.
tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
error: unable to unlink old 'gcc/config/iq2000/iq2000.md' (Interrupted system call)
error: git checkout-index: unable to create file gcc/config/lm32/lm32.c (File exists)
Checking out files: 100% (1149/1149), done.
fatal: Could not reset index file to revision 'HEAD'.
tschwinge@grubber:~/tmp/gcc/hurd $ ls -l gcc/config/iq2000/iq2000.md gcc/config/lm32/lm32.c
ls: cannot access gcc/config/iq2000/iq2000.md: No such file or directory
-rw-r--r-- 1 tschwinge tschwinge 32159 Nov 17 19:09 gcc/config/lm32/lm32.c
tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
error: git checkout-index: unable to create file gcc/fortran/expr.c (Interrupted system call)
Checking out files: 100% (1149/1149), done.
fatal: Could not reset index file to revision 'HEAD'.
tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
error: git checkout-index: unable to create file gcc/config/sol2.h (Interrupted system call)
Checking out files: 100% (1149/1149), done.
fatal: Could not reset index file to revision 'HEAD'.
tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
error: unable to unlink old 'gcc/config/i386/i386.c' (Interrupted system call)
Checking out files: 100% (1149/1149), done.
fatal: Could not reset index file to revision 'HEAD'.
tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
Checking out files: 100% (1149/1149), done.
HEAD is now at fe3e43c Merge commit 'refs/top-bases/hurd/master' into hurd/master
2010-12-22
grubber:
$ git remote update
Fetching savannah
remote: Counting objects: 582331, done.
remote: Compressing objects: 100% (124133/124133), done.
remote: Total 582331 (delta 460856), reused 578352 (delta 457598)
Receiving objects: 100% (582331/582331), 525.15 MiB | 204 KiB/s, done.
fatal: cannot pread pack file: Interrupted system call
fatal: index-pack failed
error: Could not fetch savannah
2011-06-10
coulomb.SCHWINGE, checking out binutils' master branch,
starting from an empty working directory (after an external git push):
$ git checkout -f
fatal: cannot create directory at 'gas/testsuite/gas/bfin': Interrupted system call
$ git checkout -f
error: unable to create file gas/testsuite/gas/i386/ilp32/x86-64-sse4_1-intel.d (File exists)
warning: unable to unlink gas/testsuite/gas/m68k-coff: Operation not permitted
fatal: cannot create directory at 'gas/testsuite/gas/m68k-coff': Operation not permitted
$ git checkout -f
error: unable to create file gas/testsuite/gas/h8300/h8300.exp (File exists)
error: unable to create file gas/testsuite/gas/i386/x86-64-addr32-intel.d (File exists)
error: unable to create file gas/testsuite/gas/ia64/secname.d (File exists)
error: unable to create file gas/testsuite/gas/m68k/pr11676.s (File exists)
Checking out files: 100% (12315/12315), done.
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: gas/testsuite/gas/h8300/h8300.exp
# modified: gas/testsuite/gas/i386/x86-64-addr32-intel.d
# modified: gas/testsuite/gas/ia64/secname.d
# modified: gas/testsuite/gas/m68k/pr11676.s
#
no changes added to commit (use "git add" and/or "git commit -a")
$ rm gas/testsuite/gas/h8300/h8300.exp gas/testsuite/gas/i386/x86-64-addr32-intel.d gas/testsuite/gas/ia64/secname.d gas/testsuite/gas/m68k/pr11676.s
$ git checkout -f
$ git status
# On branch master
nothing to commit (working directory clean)
Analysis
2011-06-13
Running git checkout -f under GDB:
error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists)
error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse-check.d (File exists)
error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse4_1.d (File exists)
error: git checkout-index: unable to create file gas/testsuite/gas/ppc/astest.d (File exists)
error: git checkout-index: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (File exists)
warning: unable to unlink include/cgen: Operation not permitted
fatal: cannot create directory at 'include/cgen': Operation not permitted
Again:
error: git checkout-index: unable to create file gas/config/te-vxworks.h (File exists)
error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists)
error: git checkout-index: unable to create file gas/testsuite/gas/d10v/warning-019.s (File exists)
error: git checkout-index: unable to create file gas/testsuite/gas/i860/dual03.s (File exists)
error: git checkout-index: unable to create file ld/testsuite/ld-mmix/sec-7a.s (File exists)
warning: unable to unlink ld/testsuite/ld-powerpc: Operation not permitted
fatal: cannot create directory at 'ld/testsuite/ld-powerpc': Operation not permitted
And: git duplicated content.
All these (very likely) have the same root cause: SA_RESTART restarting too
much.
With git checkout, Git uses in progress.c a SIGALRM handler (SA_RESTART;
invoked every second via setitimer(ITIMER_REAL)) to display status messages:
x % already checked out.
To avoid the status update signals every second, in
[git]/progress.c:start_progress_delay we can just return NULL (manually in
GDB, for example), then both the error: git checkout-index and the
duplicated content issues go away.
I'm guessing that when returning from a SA_RESTART signal handler, too much
of the ``syscall''s is being restarted. For example, if a file has already
been created, the restarted creation attempt would fail: File exists. If
data has been written, it might get written again (duplication issue). Then,
there are cases where unlink apparently returns EINTR, which is not kosher
either. Etc.
Do we have problems with SA_RESTART vs. the atomicity of our syscall-alikes?
IRC, freenode, #hurd, 2013-01-30
<braunr> hm, let's try to clone a huge repository
<braunr> hm, cloning a whole linux repo, and still no problem :)
<pinotree> weren't most/all the issues at unpack time?
<braunr> i don't remember
<braunr> we'll see when it gets there
<braunr> the longest part is "resolving deltas", for which ext2fs is
clearly the big bottleneck (no I/O, page-cache only, but still)
<braunr> pinotree: well, slow, but no error
IRC, freenode, #hurd, 2013-01-31
<braunr> fyi, i've tried several checkouts of big repositories, and never
got a single error
<braunr> youpi: looks like the recent fixes also solved some git issues we
had
<braunr> i could clone big repositories without any problem
<youpi> cool :)
IRC, unknown channel, unknown date.
<azeem> seems pth still doesn't work
<bddebian> Doesn't build or doesn't work?
<azeem> both
<azeem> some configure test keep grinding the CPU, same for the test suite
<azeem> which apparently runs pth_init() and never returns
<azeem> actually, pth fails to build right now
<azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union
<azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed
<azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard...
<youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus)
The runit package doesn't work, even its test suite doesn't finish.
Thomas Schwinge once was having a look at that, but this very
report is just from his memory, and his memory is dim... The problem might
either be a time stamping issue (which might be fixed by now) or it might be
the select call failing issue we're seeing from time to time. Or something
else.
?Harish Badrinath Originally answered by Samuel Thibault:
120->proc_dostop_request ( 138) = 0
Usual issue with rpctrace: it does not support fork().
I've checked a backtrace in gdb, got this:
0x0105af6c in mach_msg_trap ()
at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140,
timeout=1000020, notify=0) at msg.c:110
2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0,
timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324
3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48
4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29
5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543
and main() shows up as:
sig_unblock(sig_term);
sig_unblock(sig_child);
-> iopause(x, 2 +haslog, &deadline, &now);
sig_block(sig_term);
sig_block(sig_child);
So it simply looks like the known "signals don't interrupt select" bug.
socat needs porting. Some work has already been done in 2007, see
http://www.dest-unreach.org/socat/contrib/socat-hurd.html or contact
Thomas Schwinge.