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.

Add a new item titled:

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)

Posted 2016-11-01 14:57:30 UTC Tags:

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.

Posted 2014-01-12 12:30:18 UTC Tags:

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 :)
Posted 2013-09-25 19:59:24 UTC Tags:
ssh

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.

Posted 2013-07-03 07:16:51 UTC Tags:

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
Posted 2013-01-08 20:31:31 UTC Tags:

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)

exec memory leaks.

<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 :)
Posted 2012-12-11 10:54:54 UTC Tags:

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)
Posted 2012-12-11 10:54:54 UTC Tags:

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.
Posted 2012-03-20 21:45:31 UTC Tags:
Posted 2012-03-18 14:20:18 UTC Tags:

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.

Posted 2012-03-17 11:21:08 UTC Tags:

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.

Posted 2012-02-07 16:03:42 UTC Tags:

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.

Posted 2012-02-07 16:03:42 UTC Tags:

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.

Posted 2012-02-07 16:03:42 UTC Tags:

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.

Posted 2012-02-07 16:03:42 UTC Tags:

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.

Posted 2012-02-07 16:03:42 UTC Tags:

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.

Posted 2012-02-07 16:03:42 UTC Tags:

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.

Posted 2012-02-03 15:26:45 UTC Tags:

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();
+    }
Posted 2012-02-02 14:05:38 UTC Tags:

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.

Posted 2012-02-02 14:05:38 UTC Tags:

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.

Posted 2012-02-02 14:05:38 UTC Tags:

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.
Posted 2011-11-04 21:53:40 UTC Tags:

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
Posted 2011-09-01 07:27:33 UTC Tags:

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"
Posted 2011-07-08 20:35:03 UTC Tags:

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?

Posted 2011-07-05 22:50:43 UTC Tags:
$ 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

Posted 2011-06-13 14:44:12 UTC Tags:
$ 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.

Posted 2011-06-10 16:47:19 UTC Tags:

Open Issues

  • Debian bug #616290

  • Proper Hurdy DHCP support

  • 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 tip
    

    IRC, 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 failed
    

    IRC, freenode, #hurd, 2014-01-03:

    <congzhang> dhcp 4.3 alpha released
    <congzhang> and PATH_MAX issue was fixed
    

    IRC, 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-ports
    

    IRC, 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-ports
    

    IRC, 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
    
Posted 2011-05-20 18:14:58 UTC Tags:

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
Posted 2010-12-01 19:00:58 UTC Tags:

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

rg6dx09G.patch

< 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?

sendmsg scm creds

< 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 )
Posted 2010-11-29 16:08:30 UTC Tags:

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.ac

    • PARALLEL_MARK is not enabled; doesn't make sense so far.

    • *-*-kfreebsd*-gnu defines USE_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.host

    Nothing.

  • Makefile.am, include/include.am, cord/cord.am, doc/doc.am, tests/tests.am

    Nothing.

  • include/gc_config_macros.h

    Should be OK.

  • include/private/gcconfig.h

    Hairy. But should be OK. Search for HURD, compare to LINUX, I386 case.

    See doc/porting.html and doc/README.macros (and others) for documentation.

    LINUX has:

    • #define LINUX_STACKBOTTOM

      Defined instead of STACKBOTTOM to have the value read from /proc/.

    • #define HEAP_START (ptr_t)0x1000

      May 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
      
    • 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
      #endif
      
    • TODO

      # 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
      # endif
      
    • TODO

      # 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
      # endif
      
    • CAN_SAVE_CALL_ARGS vs. -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."
      # endif
      
    • TODO

      #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
      #endif
      

      Also see comment below, regarding mach_dep.c.

    HURD has:

    • #define STACK_GROWS_DOWN

    • #define HEURISTIC2

      Defined instead of STACKBOTTOM to 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 ...                                             */
      #endif
      

      Being on glibc, we could perhaps do similar as USE_LIBC_PRIVATES instead of HEURISTIC2. Pro: avoid SIGSEGV (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 GDB GC_find_limit_with_bound SIGSEGV startup confusion described in binutils.

    • #define SIG_SUSPEND SIGUSR1, #define SIG_THR_RESTART SIGUSR2

    • We don't #define MPROTECT_VDB (WIP comment); but Linux neither.

    • Where does our GETPAGESIZE come 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.h

    • TODO

      Cancellation stuff is Linux-only. In other places, too.

  • mach_dep.c

    • #define NO_GETCONTEXT

      open 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_pushed

      The HAVE_BUILTIN_UNWIND_INIT case is ours.

  • os_dep.c

    • TODO.
  • dyn_load.c

    For DYNAMIC_LOADING. TODO.

  • pthread_support.c, pthread_stop_world.c

    TODO.

  • TODO.

    Other files also contain LINUX and other conditionals.

  • libatomic_ops/

    • configure.ac

      Nothing.

    • Makefile, src/Makefile, src/atomic_ops/Makefile, src/atomic_ops/sysdeps/Makefile, doc/Makefile, tests/Makefile

      Nothing.

    • src/atomic_ops/sysdeps/gcc/x86.h

      Nothing.

  • b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all correct.

  • mmap, b64dd3bc1e5a23e677c96b478d55648a0730ab75

    This is (still) stale/redundant/unused, as far as I can tell.

  • parallel mark, 07c2b8e455c9e70d1f173475bbf1196320812154, pass --disable-parallel-mark or enable for us, too?

  • HANDLE_FORK, e9b11b6655c45ad3ab3326707aa31567a767134b, 806d656802a1e3c2b55cd9e4530c6420340886c9, 1e882b98c2cf9479a9cd08a67439dab7f9622924

  • Check include/private/thread_local_alloc.h re USE_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;+}
                      }
      #           endif
      
    • diff --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

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
Posted 2010-11-17 20:29:41 UTC Tags:

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.

Posted 2010-10-07 09:33:17 UTC Tags:

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:
  http://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: ^

dbus in linux kernel.

<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

hurd init.

<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 http://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>
  http://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?

discussion.

<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
Posted 2010-09-20 11:39:04 UTC Tags:

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?
Posted 2010-07-24 10:23:41 UTC Tags:
<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)
Posted 2009-10-23 06:49:26 UTC Tags:

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.
Posted 2009-10-08 12:50:56 UTC Tags:

Typing C-c (SIGINT) in a screen session (Debian package 4.0.3-14; -11 is fine):

  • shell prompt: no reaction (nothing printed)
  • sleep 10 running: ^C printed, but SIGINT is not sent.

Debian bug #522689#38.


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.


Posted 2009-10-06 21:37:48 UTC Tags:
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
Posted 2009-10-01 21:27:18 UTC Tags:

GNU Emacs mostly does work, however there are a few issues.

  • dired on a directory hangs. (Use C-g C-g to break the unresponsive operation.)

  • Configuration in src/s/: gnu.h uses bsd-common.h. gnu-kfreebsd.h uses gnu-linux.h -- we probably should too.

    • gnu-linux.h makes a few things depend on /proc (also see HAVE_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 .el to .elc files. Looked like busy-looping inside glibc. This was not reproducible so far.

  • Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in ext2fs on /media/data when resuming emacs23 build in ~/tmp/emacs/emacs23-*/ (dpkg-buildpackage -B -uc -nc 2>&1 | tee L). No modifications to emacs23-* so far, I think. Hangs always in the same place, it seems, and reproducible. Tarred to emacs23-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; syncfs involving /media/data hangs). 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 --
M-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=
M=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
Mhwinge 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;
M;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
M01;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:
M:*.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
M5:*.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
M01;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
Mm=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
Mnx=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:*.
M.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
Ml:\^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
MH: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
ME[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
ME[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
M140\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
ME[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
Mkb=\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[
M[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
Mcommand:/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=/
M/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/
M/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
Mf8 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
M192.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=/
M/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      
M                                \^K    cd src; make all                                    \^K      CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1'         \^K      LDFLA
MAGS='-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
MEMACS=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
Md`/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
Posted 2009-08-18 10:36:14 UTC Tags:

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.

Posted 2009-08-18 10:33:11 UTC Tags:

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:
  http://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:
  http://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:
  http://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
Posted 2009-07-07 20:48:47 UTC Tags:

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.

Posted 2009-05-19 10:01:42 UTC Tags:
License:

GFDL 1.2+

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

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 :)
Posted 2009-05-19 10:01:42 UTC Tags:
pth

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)
Posted 2009-05-19 10:01:42 UTC Tags:
License:

GFDL 1.2+

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

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.

Posted 2009-05-19 10:01:42 UTC Tags:

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.

Posted 2009-05-19 10:01:42 UTC Tags:
License:

GFDL 1.2+

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.