summaryrefslogtreecommitdiff
path: root/open_issues/systemd.mdwn
blob: 1055a1965d7c9d787d59723d13acf3e030a74b04 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
[[!meta copyright="Copyright © 2010, 2011, 2013, 2014, 2016 Free Software
Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="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|/fdl]]."]]"""]]

  * <http://www.freedesktop.org/wiki/Software/systemd>

  * <http://0pointer.de/blog/projects/systemd.html>,
    <http://0pointer.de/blog/projects/systemd-update.html>

  * <http://lwn.net/Articles/389149/>

Will need to have something like Linux'
[*cgroups*](http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/cgroups.txt;hb=HEAD).
Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)*
(german)](http://www.pro-linux.de/artikel/2/1464/ressourcen-verwaltung-mit-control-groups-cgroups.html),
Daniel Gollub, Stefan Seyfried, 2010-10-14.

Systemd uses Linux kernel specific mechanisms, which are not readily available
on gnumach or the GNU/Hurd.  Porting systemd to work on the Hurd is a
daunting task.  A better option is to use a portable init system, like the
the [[GNU Shepherd|open_issues/shepherd]], which is used in GuixSD.

# 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

[[glibc/debian/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

[[hurd/translator/mtab/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?

[[hurd/translator/mtab/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](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a
[message](http://lists.debian.org/debian-devel/2011/07/msg00281.html) 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|secure_file_descriptor_handling]]
  * /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