nosh version 1.40

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.40 .

 *

   http://jdebp.eu./Softwares/nosh/

 *

   http://jdebp.info./Softwares/nosh/

 *

   https://github.com/freebsd/freebsd-quarterly/blob/master/2018q4/nosh.md

This version sees changes to the doco, improvements to network 
configuration, and a change to machine ID generation.



FreeBSD binaries



I plan for this to be the last release with binaries built on FreeBSD 
10.  I am going to upgrade the build machine.



|ifconfig|



 *

   https://unix.stackexchange.com/a/504084/5132

There is now an |ifconfig| command in the toolset, with a command-line 
interface and output similar to the FreeBSD |ifconfig|. It is primarily 
intended for use on non-FreeBSD systems, to provide a FreeBSD-like 
|ifconfig| where one does not have the actual FreeBSD tool.  The 
|ifconfig@*| services generated by the external configuration import 
subsystem make use of it on Linux operating systems, allowing the 
services themselves to be pretty much the same across platforms.


It handles multiple (unlabelled) addresses per interface and both IP 
version 6 and IP version 4 addressing, which are two of the 
long-standing complaints against the old |ifconfig| programs from GNU 
inetutils  and NET-3 net-tools 
.  It has no notion of 
overwriting a single "primary" address.  It has a |broadcast1| flag for 
calculating the broadcast address from the prefix length and address.  
It prefers the new (since 1993) notation for IP version 4 network 
masks.  It can do the FreeBSD style of EUI-64 address assignment for IP 
version 6 with an |eui64| flag.


And it colours its output if writing to a terminal.  (-:


Machine ID generation

=

FreeBSD from 2007 onwards used the SMBIOS system UUID from the machine 
firmware as a fallback source for a machine ID. |setup-machine-id| prior 
to this release of the toolset would do the same for compatibility.  
This has now been removed from |setup-machine-id|. The privacy problems 
that it entails have turned out to outweigh what little utility it had.


Systems that would have fallen back upon the SMBIOS system UUID will now 
fall back to creating UUIDs using the C library.  Note that the FreeBSD 
C library still uses MAC addresses to create UUIDs.  The OpenBSD and GNU 
C libraries use CSPRNGs.


There is also now an |erase-machine-id| command that resets all of the 
machine ID storage locations set by |setup-machine-id| to a nil UUID.  
The |machine-id| service now calls |erase-machine-id| at shutdown.


Thus: Machine IDs (when using the supplied service bundles) now have a 
lifetime from bootstrap to shutdown, will not persist across reboots, do 
not reveal the SMBIOS system UUID and are not constant and correlatable 
because of it even when explicitly wiped, and can still reveal MAC 
addresses on FreeBSD.


The new |machine-id|(7) manual page lists some of the known users of 
machine IDs, explains where machine IDs are stored, and gives some of 
the history of machine IDs.



Square mode

===

Square mode is now switchable in |console-terminal-emulator|, using DEC 
Private Mode 1369. |console-control-sequence| has a |--square| option 
for changing it.



Other tools

===

|ucspi-socket-rules-check| has gained the ability to check |uid/self/| 
and |gid/self/| subdirectories when handling UCSPI-UNIX connections.



Doco



The Guide now includes the original command manuals, written in DocBook 
XML.  These are directly readable using a GUI WWW browser and the 
supplied stylesheet.  The conversions to HTML are still supplied, but 
reading the original DocBook XML format is better.


TUI WWW browsers such as lynx cannot read DocBook XML.  Their deficiency 
has inspired a new |console-docbook-xml-viewer| tool that parses and 
displays the manual pages with a simple full-screen interface on a 
terminal.  This can of course display other DocBook XML manual pages as 
well.



External configuration import improvements

==

The external configuration import subsystem now allows various 
extensions in a |/etc/network/interfaces| file, including |ipv4ll| 
stanzas (which will cause |avahi-autoipd| services to be set up) and 
|eui64| stanzas.  A "|broadcast +|" setting is now transformed into the 
aforementioned |broadcast1| flag for |ifconfig|.


It also now once more treats |false| for the login shell as signifying a 
non-personal user account.



More service bundles



There are a few more service bundles in this release, including ones for 
Laurent Bercot's mdev, for two-ftp, and for NcFTPd.

djbwares version 9

[Jonathan de Boyne Pollard]

The djbwares package is now up to version 9 .

 *

   http://jdebp.eu./Softwares/djbwares/

 *

   http://jdebp.info./Softwares/djbwares/

This version sees changes to the doco and to the DNS and HTTP servers.


FreeBSD binaries


I plan for this to be the last release with binaries built on FreeBSD 
10.  I am going to upgrade the build machine.



Doco


All of the manuals are now DocBook XML, and the hodgepodge admixture of 
manuals from three sources is gone.  A stylesheet is supplied for 
reading the manuals directly using a GUI WWW browser.  They can also be 
read using the |console-docbook-xml-viewer| tool from version 1.40 of 
the nosh toolset.


The long-missing |tcp-environ| manual is now present.


HTTP servers


Hand in hand with the documentation improvement, |httpd| now has content 
types for the |.xml| and |.xhtml| filename extensions.



DNS servers
===

 *

   http://jdebp.eu./Softwares/djbwares/qmail-patches.html#any-to-cname

 *

   http://jdebp.info./Softwares/djbwares/qmail-patches.html#any-to-cname

The |ANY| query type in the DNS has never meant ALL, and has never 
really been useful.  Pretty much only one software even made use of 
|ANY| for non-testing purposes.  That was qmail, which I patched not to 
do so back in 2003.


Although the diagnostic tools still support sending |ANY| queries, with 
one exception, in this release all of the DNS server softwares now 
synthesize non-responses, containing an invariant |HINFO| resource 
record set, to |ANY| queries.  The specialized content DNS servers 
simply return such responses straightforwardly, as they do not have to 
worry about |CNAME| chains, which they do not ever construct.  The other 
DNS servers have to handle |CNAME| chains.


The general-purpose |tinydns| and |axfrdns| content DNS servers will 
continue to process |CNAME| chains as before, but will return a 
synthesized |HINFO| resource record set at the end of the chain. 
|dnscache| also processes |CNAME| chains as before, again returning the 
chain with a synthesized |HINFO| resource record set at the end.  It no 
longer allows |ANY| queries as a loophole for retrieving cache contents, 
and will not issue |ANY| queries from its back end.


The diagnostic tool that is the exception is |tinydns-get|, whose 
operation is supposed to exactly replicate what |tinydns| does.  It, 
too, now synthesizes non-responses when an |ANY| lookup is requested.

Re: get my ip address

[Jonathan de Boyne Pollard]

tony;

I am aware that I can call ip a and parse the result. [...]

Is there any other way to obtain this data, maybe from /sys?


just call libc.getifaddrs() directly.

* 
http://programmaticallyspeaking.com./getting-network-interfaces-in-python.html

Re: stracing login process with systemd?

[Jonathan de Boyne Pollard]

Eduard Bloch:


that was the best guess I could extract from the documentation


Try some StackExchange answers.

* https://unix.stackexchange.com/a/477049/5132

* https://unix.stackexchange.com/a/427917/5132

* https://unix.stackexchange.com/a/423648/5132

* https://unix.stackexchange.com/a/441831/5132

* https://unix.stackexchange.com/a/500687/5132

Re: Why /usr/sbin is not in my root $PATH ?

[Jonathan de Boyne Pollard]

Greg Wooledge:


At some point I'm going to need to write a wiki page to explain the 
change, and list some known workarounds, so that users can pick which 
one they want to implement.



You could point them to StackExchange in the meantime.  (-:

* https://unix.stackexchange.com/a/460769/5132

Re: No ifconfig

[Jonathan de Boyne Pollard]

 *

   https://lists.debian.org/debian-user/2017/08/msg01613.html

 *

   https://news.ycombinator.com/item?id=17152738

 *

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274269

 * https://news.ycombinator.com/item?id=17151922

Since I needed an |ifconfig| with a more BSD-like interface /anyway/ so 
that I didn't have to maintain highly divergent scripts, you are going 
to gain in the future.


|ifconfig| from GNU inetutils 
:


   jdebp % inetutils-ifconfig -l
   enp14s0 enp15s0 lo
   jdebp % inetutils-ifconfig lo
   loLink encap:Local Loopback
  inet addr:127.0.0.1  Bcast:0.0.0.0  Mask:255.0.0.0
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:9087 errors:0 dropped:0 overruns:0 frame:0
  TX packets:9087 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:51214341  TX bytes:51214341

   jdebp %

|ifconfig| from NET-3 net-tools 
:


   jdebp % ifconfig -l
   ifconfig: option `-l' not recognised.
   ifconfig: `--help' gives usage information.
   jdebp % ifconfig lo
   lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
inet6 ::2  prefixlen 128  scopeid 0x80
loop  txqueuelen 1000  (Local Loopback)
RX packets 9087  bytes 51214341 (48.8 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 9087  bytes 51214341 (48.8 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

   jdebp %

|ifconfig| from an unreleased version of the nosh toolset 
:


   jdebp % ifconfig -l
   enp14s0 enp15s0 lo
   jdebp % ifconfig lo
   lo
link up loopback running
link address 00:00:00:00:00:00 bdaddr 00:00:00:00:00:00
inet4 address 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1
inet4 address 127.53.0.1 prefixlen 32 bdaddr 127.53.0.1
inet6 address ::2 scope 0 prefixlen 128
inet6 address ::1 scope 0 prefixlen 128
   jdebp %

FreeBSD |ifconfig| (on a different system) for comparison:

   JdeBP % ifconfig lo0
   lo0: 
flags=ffde8149
 metric 0 mtu 16384
options=63
inet6 ::2 prefixlen 128
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
inet 127.53.0.1 netmask 0xff00
nd6 options=61
   JdeBP %

The |ifconfig| from an unreleased version of the nosh toolset 
 on that other system:


   JdeBP % ifconfig lo0
   lo0
link up loopback drv_running running promisc multicast ppromisc monitor 
staticarp renaming
nd6 performnud auto_linklocal noradr
 rxcsum txcsum hwcsum rxcsum_ipv6 txcsum_ipv6
link address lo0 metric 0 mtu 16384
type 24 linkstate 0 physical 0 baudrate 0
inet6 address ::2 scope 0 prefixlen 128
inet6 address ::1 scope 0 prefixlen 128 bdaddr ::1 scope 0
inet6 address fe80::1 scope 3 prefixlen 64
inet4 address 127.0.0.1 prefixlen 8 bdaddr 127.0.0.1
inet4 address 127.53.0.1 prefixlen 8 bdaddr 127.53.0.1
   JdeBP %

Let's play "Where is X?" (was: logout kills X)

[Jonathan de Boyne Pollard]

Felix Miata:

Indeed. It's what I had in mind when I responded. I'll give one guess 
where it came from. Time's up. Yes, systemd. Who couldn't have 
guessed. It imposed a notion that I first noticed (wish to guess 
where?) Yup, on Fedora, home of Leonard P, under the aegis of RedHat, 
and Gnome. that X somehow belongs on |tty1| instead of |tty7|.


This is quite wrong.  Neither systemd nor Lennart Poettering imposed 
such a notion.  The RedHat people had the idea of moving the X server to 
|tty1| in 2008.  It wasn't Lennart Poettering's idea, as can be seen by 
reading the list of people on the Fedora doco of the idea, and it 
pre-dates systemd's /very invention/ by two years.  It was motivated by 
reducing mode-change flicker during the boot process, by avoiding KVT 
switching, and at the time Fedora was using upstart.  Ironically, the 
idea /was imposed upon/ systemd and Lennart Poettering, which had to 
adjust to accommodate it.


 *

   https://news.ycombinator.com/item?id=12772915

 *

   https://news.ycombinator.com/item?id=16104343

The problem with the Bourne Again shell package's |clear_console| /is/ 
KVT switching, and /similarly eliminating KVT switching/ fixes it (as I 
explained back in 2015, when I published a replacement |clear_console| 
 that 
did not do KVT switching).  There is nothing special about |tty1| here; 
and this is everything to do with a Bourne Again shell package tool that 
uses a bodge to clear KVTs, and nothing to do with systemd.

Re: logout kills X

[Jonathan de Boyne Pollard]

Greg Wooledge:

The man page for |clear_console|(1) is a little unclear to me, and a 
little bit disturbing. I cannot figure out what "changes the 
foreground virtual terminal to another terminal" is supposed to mean, 
but between that and the reference to |chvt|(1) under SEE ALSO, it 
seems like someone might want to investigate that more closely.


I already did, years ago.  It is why I years ago wrote and published a 
replacement |clear_console 
| that 
just uses the control sequences to clear the scrollback buffer, gaining 
the benefit of working remotely, with GUI terminal emulators, and with 
PuTTY along the way.  It has been in the nosh toolset since version 1.19 
in 2015.  The original |clear_console| from the Bourne Again shell 
package is, in contrast, using the side-effects of switching between 
KVTs as a way of clearing the scrollback buffer.  It switches them back 
and forth very rapidly.


I explained this in this very mailing list three years ago 
. I also 
explained it in the 1.19 announcement 
, also on 
this very mailing list, pointing to a whole bunch of Debian bugs. I also 
explained it on Unix and Linux StackExchange 
.  It's even explained in 
the manual.  (-:

Re: Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Jonathan de Boyne Pollard]

Thorsten Glaser:

> Just accept that this idea, originating from the systemd people at 
Fedora/Freedesktop, is NOT welcome to classical Unix people.


Ahem!  We classical Unix people experienced this idea in the late 1980s, 
from where it *really* originated, Sun and AT&T.


* https://groups.google.com/d/msg/comp.sys.sun/K9286yRtZ8c/Abwzdo05gMMJ

The separate /sbin that you are asserting to be classical Unix and 
suggesting as the place to put things here, actually was not classical 
Unix in the first place.  Sun's Rusty Sandberg is credited with 
inventing the ideas of /var and /sbin which the world gained with SunOS 
4.0 in 1988, a year before AT&T System 5 Release 4 put it into /usr as 
/usr/sbin with only a symbolic link at /sbin, and two years before 
4.3BSD Reno adopted it in 1990, the BSD world having to that point used 
/etc for such binaries.  Having things in lots of directories under /usr 
(/usr/amdahl/bin, /usr/ucb, /usr/5bin, /usr/3bin, /usr/eun, 
/usr/stanford/bin, /usr/brl, /usr/bbn, /usr/jerq/bin, and so on) 
*pre-dates* the very idea of /sbin on Unix and was how things were for 
most of the 1980s and the 1970s.


* 
https://groups.google.com/d/msg/comp.unix.questions/g9DsvKQx8h8/QNs0F-mHpR4J


* https://unix.stackexchange.com/a/448799/5132

* https://groups.google.com/d/msg/comp.unix.wizards/pLc_jhCUDtU/WD92a732Nx4J

Almost everything in *lots* of pseudo-user directories under /usr was 
the actual classical Unix way.

nosh version 1.39

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.39 .

* http://jdebp.eu./Softwares/nosh/

* 
https://www.freebsd.org/news/status/report-2017-07-2017-09.html#The-nosh-Project 



* http://jdebp.info./Softwares/nosh/

I missed announcing 1.38, so this announcement will cover both versions.

These versions see a major addition to the user-space virtual terminal 
subsystem, various other changes in several areas, the completion of 
some items mentioned as placeholders in version 1.37, and some bug fixes.



Completed placeholders
==

make-read-only-fs is now fully implemented, and is no longer a placeholder.


More service bundles


There are several more additions to the set of service bundles supplied 
with the toolset: connman, ofono, dundee, cntlm, minidlna, powertop, 
alsa-state, alsa-restore, unattended-upgrade-shutdown, apt-daily-update, 
apt-daily-upgrade, LCDd, phpsessionclean, tinysshd, watchman, rngd, 
isnsd, isnsdd, usbmux, and VBoxBalloonCtrl.  atd is now a Linux-only 
service, with the BSDs now having an atrun service.



More packages
=

The new nosh-run-bcron, nosh-bcron-as-cron-shims, nosh-debian-crontab, 
and nosh-debian-crontab-anacron packages deal in running the services 
and providing the data files for various cron toolsets.  The former two 
deal in bcron, running its services and providing the crontab command as 
an alias for bcrontab; and the latter two (only available for Linux 
operating systems) deal in Debian's /etc/crontab file.


The new nosh-openrc-shims package contains shims for OpenRC's rc-service 
and rc-update commands.  And the new nosh-run-via-open-rc package 
contains OpenRC scripts for running the service manager.


The new nosh-linux-shims package contains shims for commands to be found 
in the non-portable util-linux toolset, such as setterm (more on which 
later).


The Debian desktop and server base -run packages no longer preset ntpd 
and openntpd, on the grounds that a range of such services exist and 
these are not necessarily the installed softwares.



More tools
==

New commands include getuidgid, userenv-fromenv, setgid-fromenv, envgid, 
printenv, setlogin, console-decode-ecma48, console-control-sequence, 
console-flat-table-viewer, console-input-method, and 
local-stream-socket-connect.


The userenv command is now a combination of two of these new commands, 
getuidgid and userenv-fromenv.  It has also gained options for not 
setting SHELL and USER/LOGNAME.


setlogin sets the login account that is associated with a kernel 
session, as returned by the logname command.


printenv is roughly equivalent to the conventional tool of the same 
name, except that it is a nosh/exec built-in command and that it 
supports several forms of output (including properly quoted rc.conf 
form, NUL-terminated form, and envdir form) in addition to the 
conventional human-readable form.  This built-in command makes a common 
idiom easier.  When combining clearenv, read-conf/envdir, and printenv 
to read a configuration setting, before the advent of the built-in 
command one had to employ `command -v printenv` (because clearenv unsets 
PATH).  Now one can invoke it as simply printenv.


One common use of this idiom is by the toolset's own build system and by 
the external configuration import subsystem, to read things like the 
amalgamated /etc/system-control/convert/rc.conf and an os_version file.  
Further to this, the amalgamated rc.conf now has an os_version setting 
on Linux operating systems, consolidating the code for obtaining that in 
one place.


console-flat-table-viewer is a full-screen TUI viewer for various sorts 
of common flat database tables.  It decodes the vis(3) encoding that is 
employed in various FreeBSD system tables.  It also handles tables that 
use the standard ASCII US, RS, GS, and FS characters.  File separators 
permit a form of continual update and redisplay if used in combination 
with pipes.


local-stream-socket-connect is the AF_LOCAL socket equivalent of 
tcp-socket-connect.



Improvements to existing tools and bug fixes


The Z shell completions now function better, and now cover a lot more of 
the commands in the toolset.


systemd service unit conversion has been modified to make use of the new 
environment commands.  The conversion tool in particular makes use of 
these when converting per-user Desktop Bus services.  The 
EnvironmentUser extension has been replaced by an EnviromnentUserOnly 
extension, so that User and Group are consistently the sources of the 
user account and primary group. Additional settings now supported by 
convert-systemd-units include RuntimeDirectoryGroup, 
RuntimeDirectoryPreserve, WantsMountsFor, AfterMountsFor, and 
RequiresMountsFor.


convert-systemd-units now also supports %T, %V, and %E expansions and 
snippets files.


By analogy to \S, the login-banner command now also recognizes the \N 
sequence.


The extern

Re: Systemd and forking programs (was systemd can't start a dæmon and doesn't give any error either)

[Jonathan de Boyne Pollard]

to...@tuxteam.de:

Inittab was the original way of doing things for AT&T, BSD copied 
that, and SysV grafted /etc/init.d onto it. Slowly other unices 
followed (alas!).




Some history seems in order.

There wasn't really an original way of doing things, as in First Edition 
Unix this stuff, including starting up mel's da program, was simply 
hard-coded into the init program itself.  One can enjoy seeing 
/usr/mel/da and the rest in the resurrected 1st Edition source.


By the time of Seventh Edition and 4BSD, init was running /etc/rc and 
terminals were listed in /etc/ttys.  The BSDs stuck with this for 2 to 3 
decades more (depending from the BSD).  AT&T on the other hand changed 
to an inittab system with run-levels in System 3 at the start of the 1980s.


In the AT&T world, inittab was soon augmented and superseded, within a 
decade.  By the time of System 5 Release 4 in 1988 handling of terminal 
login had been moved out of inittab to the Service Access Facility, 
specifically to ttymon.  IBM AIX likewise gained the System Resource 
Controller in version 3.1 two years later, and reduced the number of 
run-levels actually used to just 1 (everything in inittab being marked 
as run level "2").  This left comparatively very little in inittab on 
those systems and in practice did away with the run-level system on Unix 
in the AT&T side of the universe.


By 1990.

Yes, run-levels and a lot of /etc/inittab were obsolete before Linux was 
even invented.


* http://jdebp.eu./FGA/run-levels-are-history.html

Two years after that Miquel van Smoorenburg cloned the old System 5 
init+rc system for Minix, but did not clone the more recent Service 
Access Facility or anything like the SRC; meaning that terminal login 
was back to the old inittab way of operating, inittab was back to being 
full of stuff, and run-levels were back.  Most Linux operating systems 
adopted it.  van Smoorenburg init had several different rcs to accompany 
it.  By the late 1990s there were so-called sysv-rc, the van Smoorenburg 
one, and file-rc developed from Winfried Truemper's r2d2.  van 
Smoorenburg init itself did not stay static, splitting the old single 
user mode into emergency and rescue modes in 1995, although it took 
about 5 years for the names to fully catch on.


* http://jdebp.eu./FGA/emergency-and-rescue-mode-bootstrap.html

In the BSD world, things were quite turbulent as well, as the 
edit-this-single-monolithic-shell-script system was proving troublesome 
in real world use.  One paper from the 1991 LISA conference published by 
USENIX talked about how /etc/rc.local had accrued all of the very same 
problems of /etc/rc that had caused /etc/rc.local to be split out in the 
first place.  FreeBSD re-engineered /etc/rc.local into an 
/etc/rc.local.d/ system with drop-in files in 1995,  and outright got 
rid of /etc/rc.local in 1998.  (The commit that deleted it was made by 
one Matthew Dillon, after encouragement from Jordan Hubbard.)  There was 
a big discussion at the end of the decade, which culminated in Mewburn 
rc replacing the old /etc/rc in NetBSD 1.5 in 2000, and in FreeBSD in 
2002.  Mewburn rc did not have run levels, and learned from experience 
of van Smoorenburg rc, organizing things so that rc scripts were (as 
intended and often, but alas far from always) a few lines of variable 
assignments and just two commands.  Gentoo's OpenRC went down the same 
route years later in 2007.  Debian's variant of van Smoorenburg rc 
started going down the same route almost as long again after that, in 2014.


OpenBSD was the lone holdout, hanging on to the old 4BSD way until 2011 
when it switched to a system similar to, but not the same as, Mewburn rc.


* http://jdebp.eu./FGA/rc.local-is-history.html

In the Linux world, there were then simpleinit, jinit, minit (once 
packaged and part of Debian), runit-init (still packaged and part of 
Debian) depinit, GNU dmd, pinit, initng, eINIT, upstart, finit, systemd, 
nosh system-manager, s6-rc, and Epoch.  Over the same period, Solaris 
switched to the SMF and MacOS switched to launchd.


* http://jdebp.eu./FGA/inittab-is-history.html

* https://blog.darknedgy.net/technology/2015/09/05/0/

Re: anacron mysteriously not working

[Jonathan de Boyne Pollard]

Michael Lange:

[...] I discovered that the syslog had become rather huge, so 
apparently logrotate had not been performed for months.




See the thread started by John Cunningham on this very mailing list on 
this topic 6 days before you did.

Re: Jessie: No logrotate since October 2016?

[Jonathan de Boyne Pollard]

John Cunningham:

I hate to wade into the pool of systemd hate, but is this systemd's 
fault? I noticed anacron doesn't exist on this system. Is it supposed 
to anymore? Or is that one of the things that have been deprecated? If 
so, how are the /etc/cron.daily jobs getting run these days?


You'll have to check the timeframe of when these changes happened with 
respect to Debian 8, but a Debian 9 system does not use cron to run 
anacron and various other things like phpsessionclean, nor use anacron 
itself to run various further things.  You'll find [ ! -d 
/run/systemd/system ] in various places in Debian Linux nowadays that 
turns stuff off when systemd is running, as well as reliance on the fact 
that systemd ignores non-native stuff if it has native stuff of the same 
name (such as anacron.timer).


* https://unix.stackexchange.com/a/438379/5132

* https://sources.debian.org/src/anacron/2.3-24/debian/anacron.timer/

* https://sources.debian.org/src/apt/1.6.1/debian/apt.apt-compat.cron.daily/

* https://sources.debian.org/src/man-db/2.8.3-2/debian/cron.daily/

Moreover, you will find the similar [ -x /usr/sbin/anacron ] in various 
places to control what happens when anacron is not installed.


* https://sources.debian.org/src/cron/3.0pl1-130/debian/crontab.main/

So bear in mind that your learned ideas about what runs what are no 
longer true.

Re: Invalid UTF-8 byte? (was: Re: utf)

[Jonathan de Boyne Pollard]

Henrique de Moraes Holschuh:

Also, a text file MAY contain NULs (the character), it is just 
considered bad practice (nowadays?). Don't assume you won't see any. 
For example, received e-mail is *more* likely to have NULs in it than 
normal text due to the quality of some mail agents out there.


I suspect not as likely as anything that was in the process of being 
appended to on a not-fully-journalling filesystem when a dirty shutdown 
happens.  (-:


* https://askubuntu.com/questions/356981/

Or anything that "rotates" output files by truncating them and pulls the 
rug out from underneath an old-style simplistic indefinitely-running 
text output writer.


* http://jdebp.eu./FGA/do-not-use-logrotate.html#Background

Re: Invalid UTF-8 byte? (was: Re: utf)

[Jonathan de Boyne Pollard]

rhkramer:


Where were you in 2000 when I started the project?

I cannot speak for anyone else, but I was probably once again giving a 
frequently given answer that I eventually put up on a WWW page.


http://jdebp.eu./FGA/mail-mbox-formats.html

Re: Invalid UTF-8 byte? (was: Re: utf)

[Jonathan de Boyne Pollard]

rhkramer:

The reason I wanted such a byte was to use it as a record separator in 
a set of text files (that I use as an askSam "workalike" (or 
"worksimilar") so that I could use msort (which depends on a 1 byte 
record separator to --separate the records ;-) while sorting. Some of 
the files already include UTF-8, and, in the future, I anticpate all 
will be in UTFF-8.


Note that ISO 646, hence ISO 8859, hence ISO 10646, has had a 
single-byte Record Separator character since the 1960s.  (-:

Re: Ideal place to set environment variables

[Jonathan de Boyne Pollard]

Greg Wooledge:

If there existed a single, universal, simple answer, don't you think 
we would have put it on the wiki page?




I think that login.conf is a step in the right direction, and I'm 
planning on making tools that support it.  Or, rather, on making the 
tools that already support it on the BSDs also support it on Linux 
operating systems.


* http://netbsd.gw.com/cgi-bin/man-cgi?login.conf

* https://www.freebsd.org/cgi/man.cgi?query=login.conf

* https://man.openbsd.org/login.conf

* http://jdebp.eu./Softwares/nosh/guide/userenv-fromenv.html

I already use them to set the GUI environment from login.conf on TrueOS.

* https://unix.stackexchange.com/a/390089/5132

Re: Spurious character typed on console every ~20 secs until logged in

[Jonathan de Boyne Pollard]

David Wright:


an extra ^@ character¹



Unix & Linux Stack Exchange had this last year.

* https://unix.stackexchange.com/questions/395494/

* https://unix.stackexchange.com/questions/396192/

* https://unix.stackexchange.com/questions/360830/

Re: restarting ntp

[Jonathan de Boyne Pollard]

Michael Grant:

It's the last line in the file in the [Service] section.  A little 
research shows that this line seems to belong in the [Unit] section.


The people that you should talk to are Lennart Poettering who wrote 
that, and Zbigniew Jędrzejewski-Szmek who reviewed it.


* 
https://github.com/systemd/systemd/commit/7ddcdb6072745fe96dee4df08f5f874c057069e4


* https://github.com/systemd/systemd/pull/8335

Origin of /var/run contents

[Jonathan de Boyne Pollard]

Greg Wooledge:

Wheezy used sysvinit and related pacakges, not systemd. Jessie does 
have the file-hierarchy(7) man page that Jonathan mentioned.


Debian 7 had systemd, and the sharp-eyed who read the URL will have 
noticed that I pointed to the Debian 7 version of that manual page.


Have a manual page from Ubuntu 14, which likewise did in fact have 
systemd, to go with it:


* http://manpages.ubuntu.com/manpages/trusty/man8/pam_systemd.8.html

This stuff does go back quite a number of years, now.

* 
https://lists.freedesktop.org/archives/systemd-devel/2010-October/000686.html



Greg Wooledge:


All of the stuff Jonathan is describing is from systemd,

The sharp-eyed will have also spotted that that is untrue.  At least one 
of the things that I pointed to most definitely is not systemd.

Origin of /var/run contents

[Jonathan de Boyne Pollard]

Gene Heskett:


Didn't anyone think of the stuff that runs as a user?

They did.  They gave you a /run/user/$UID directory owned by you, and an 
XDG_RUNTIME_DIR environment variable whose value points to it that you 
use so that its location is configurable.  They also gave you a manual 
entry.


* 
https://freedesktop.org/software/systemd/man/file-hierarchy.html#Runtime%20Data


* 
https://manpages.debian.org/wheezy/systemd/file-hierarchy.7.en.html#RUNTIME_DATA


* https://unix.stackexchange.com/questions/162900/

* http://jdebp.eu./Softwares/nosh/guide/gazetteer.html#user-runtime

* http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html

* https://wiki.debian.org/ReleaseGoals/RunDirectory

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635131

* 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/migration_planning_guide/sect-red_hat_enterprise_linux-migration_planning_guide-file_system_layout#sect-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-File_System_Layout-Changes_to_the_run_directory

Re: Origin of /var/run contents

[Jonathan de Boyne Pollard]

Dave Sherohman:


Or should I be going about this in a completely different manner?



Yes.


[Service]
Type=simple
User=starman
RuntimeDirectory=starman

And simply do not use the --pid and --daemonize options in the first 
place.  You are using a service manager that tracks child processes and 
that runs things in dæmon context to begin with. Employing the rickety 
and dangerous PID file mechanism and vain attempts at self-dæmonization 
is quite wrong.


* 
http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotCreatePIDFiles


* 
http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotBackgroundise

hostname

[Jonathan de Boyne Pollard]

Linux/Unix hostname resolution is only done by consulting respected 
services, not by everyone announcing themselves in broadcast mode.




Greg Wooledge, meet mDNS and avahi/Bonjour.  (-:

* http://multicastdns.org/

SSL inspection

[Jonathan de Boyne Pollard]

Reco:

Browsers do certificate validation, "wrong IP address" would be 
possible if the third party somehow produced a valid certificate for 
wiki.debian.org (you have to be a CA *or* the government to do this) 
and faked a DNS record (that's easy part).


One can also do it if one is the person's employer and owns the machine 
that the employee is running, no DNS resource record modifications 
required, merely the employer as an additional root authority pushed out 
via group policy or suchlike and either custom proxy auto-configuration 
or transparent proxying at the borders.  This has been a known practice 
for many years, and there have been for that time a wide range of 
products sold to employers for specifically doing this.


* https://technet.microsoft.com/en-gb/library/ee658156.aspx

* http://cookbook.fortinet.com/why-you-should-use-ssl-inspection/

* https://securebox.comodo.com/ssl-sniffing/ssl-inspection/

* https://www.zscaler.com/products/ssl-inspection

* https://www.globalsign.com/en/blog/what-is-ssl-inspection/

... and so on.

failed to set console font and keymap

[Jonathan de Boyne Pollard]

Anil Duggirala:


Actually, the error says. "Failed to start Set console font and keymap".



That is the description of a service.  Read the journal with systemctl 
status and journalctl to see what has been logged about why it has failed.

Re: What is available for setting services to run levels

[Jonathan de Boyne Pollard]

Harry Putnam:

What tools do we have for setting services to run levels


As of Debian 8, you are using a systemd operating system.  Forget about 
runlevels.  They are, as the systemd doco says several times over, 
"obsolete".


* https://unix.stackexchange.com/a/196014/5132

* https://unix.stackexchange.com/questions/210117/

* https://unix.stackexchange.com/a/394238/5132

* http://jdebp.eu./FGA/inittab-is-history.html

nosh version 1.37

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.37 .

 *

   http://jdebp.eu./Softwares/nosh/

 *

   
https://www.freebsd.org/news/status/report-2017-07-2017-09.html#The-nosh-Project

 *

   http://jdebp.info./Softwares/nosh/

Some of the changes in this release are works in progress, that you will 
see fully realized in version 1.38 or later.


Changes include:

 *

   There is a new chapter in the /nosh Guide/ for those wishing to make
   packages and ports of other softwares, or add service bundle support
   to existing packages and ports.

 *

   The external formats configuration import subsystem has been
   reorganized a bit.

 o

   Nothing uses the |JAVA_HOME| import system any more, where
   service bundles explicitly have their |JAVA_||HOME| variables
   set by configuration import, although it is retained.  All
   service bundles instead use the |find-matching-jvm| mechanism to
   auto-detect a JVM matching their chosen criteria at start time.

 o

   The per-user services import is now in two parts. System-wide
   import sets up a |$HOME/.config/service-bundles/convert/|
   subdirectory for each (real user) user account; and each user
   can then use that, which contains a subordinate per-user
   configuration import mechanism, to set up imported per-user
   service bundles for things.

 o Per-user service source files for Desktop Bus and other services
   are now in their own subdirectory, as are converted keyboard
   maps for the userspace virtual terminals.
 *

   |static-networking| external format configuration import has been
   enhanced to set up |snort@/interface/| services and to handle
   |ipv6_cpe_wanif| and |ipv6_activate_all_interfaces| from |/etc/rc.conf|.

 *

   There is a new |make-read-only-fs| chain loading tool that is a
   placeholder for now.  It is used in some service bundles generated
   by the |convert-systemd-units| tool, which now recognizes and
   converts |CPUAffinity|, |ProtectHome|, |ProtectSystem|,
   |ReadWriteDirectories|, |ReadOnlyPaths|, and |InaccessiblePaths|
   settings.

 *

   Per-user management has been augmented, finally fixing the problem
   of |system-control| locating the per-user manager by giving the
   per-user manager an optional listening FIFO open file descriptor,
   which it uses to listen for user-wide state change commands.
   |system-control --user| |halt|/|normal|/|sysinit|/&c. now send
   commands via this FIFO, and each user's |user-services@/username/|
   service bundle now uses |fifo-listen| to set up the FIFO and creates
   the |per-user-manager/| subdirectory in |/run/user|.

 *

   There are some more service bundles in the collection that comes
   with the toolset: clickhouse-server, hue, udhcpc-log, minissdpd,
   rtkit-daemon, accounts-daemon, gdm3, speech-dispatcher, gdomap,
   blueman-mechanism, and sysvipc.

 *

   The per-user configuration import now recognizes and sets up
   per-user service bundles for a whole lot more per-user services.

 *

   On FreeBSD/TrueOS systems |setup-machine-id| now writes
   |/usr/local/etc/machine-id|.

 *

   The userspace virtual terminal services, the multiplexor and the
   terminal emulators, no longer run under the aegis of the |daemon|
   system account.  Rather, they now have their own dedicated accounts
   under whose aegides they run.  To go with that, there is now a
   |user-vt-realizer| group to which users can be added to grant them
   realizer (i.e. front-end I/O) access to the system-wide userspace
   virtual terminals.

 *

   A common build problem across several toolsets that occurs if one
   has set a |CDPATH|, has been fixed.  Various tweaks have also been
   made to make life easier for Archnosh and ports to other operating
   systems.

djbwares version 7

[Jonathan de Boyne Pollard]

djbwares is now at version 7.

 *

   http://jdebp.eu./Softwares/djbwares/

 *

   http://jdebp.info./Softwares/djbwares/

There are only a few changes.  A common build problem across several 
toolsets that occurs if one has set a |CDPATH|, has been fixed. 
|dnscache| now has a |FORWARDFIRST| mode.  And a bug in |tcpserver| that 
manifests itself when |tcpserver| inherits no open standard I/O file 
descriptors has been fixed.

redo version 1.4

[Jonathan de Boyne Pollard]

redo is now at version 1.4

 * http://jdebp.eu./Softwares/redo/

The only change from 1.3 is a belt-and-braces protection mechanism that 
prevents cleanup code from being told to delete a parent directory.

Re: systemd 237-1: problem starting dnsmasq

[Jonathan de Boyne Pollard]

Michael Biebl:

If other services depend on dnsmasq, please keep 
https://www.lucas-nussbaum.net/blog/?p=877 in mind


Please do not.  It is an erroneous conclusion based upon a faulty 
analysis that conflates the readiness protocols 
 with 
the non-daemon nature of the way that things are run by the |service| 
command 
 
with the van Smoorenburg system, falsely attributing the output 
behaviour caused by the latter to the former.


The correct approach follows this maxim:

If the many years of pressure have led to a program having a way to run 
under daemontools, and that is even documented right there in the 
program's manual page, then that is also very likely the best way to run 
it under systemd, too.  The requirements that the systemd people put 
forward for what they naïvely call "new-style dæmons" are in fact /the 
same/ behaviours that the daemontools world has lobbied for for the past 
couple of decades (and has fairly widely succeeded in obtaining over 
that time), and that IBM was setting out fast approaching a quarter of a 
century ago.


* http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html

That is the case here, using the daemontools mode is how to address this 
problem, and the original service unit file (in |contrib/systemd/|) did 
in fact get this right:



--- systemd.service.original2018-02-07 19:44:24.0 +
+++ systemd.service2018-02-07 19:58:36.307113285 +
@@ -6,8 +6,10 @@
 After=network.target

 [Service]
-Type=forking
-PIDFile=/run/dnsmasq/dnsmasq.pid
+Type=simple
+RuntimeDirectory=dnsmasq
+RuntimeDirectoryMode=0755
+ExecStartPre=/bin/chown dnsmasq:nogroup %t/dnsmasq

 # Test the config file and refuse starting if it is not valid.
--- init.original2018-02-07 19:44:24.0 +
+++ init2018-02-07 20:06:25.215113285 +
@@ -292,13 +292,8 @@
 stop_resolvconf
 ;;
   systemd-exec)
-# /run may be volatile, so we need to ensure that
-# /run/dnsmasq exists here as well as in postinst
-if [ ! -d /run/dnsmasq ]; then
-   mkdir /run/dnsmasq || return 2
-   chown dnsmasq:nogroup /run/dnsmasq || return 2
-fi
-exec $DAEMON -x /run/dnsmasq/$NAME.pid \
+  # systemd's mechanisms handle the runtime directory.
+exec $DAEMON --keep-in-foreground \
 ${MAILHOSTNAME:+ -m $MAILHOSTNAME} \
 ${MAILTARGET:+ -t $MAILTARGET} \
 ${DNSMASQ_USER:+ -u $DNSMASQ_USER} \

Re: policy around 'wontfix' bug tag

[Jonathan de Boyne Pollard]

Michael Stone:

Anyway, if there was a simple solution someone would have implemented 
it by now.


Indeed, that is the case; and it has been around for almost as long as 
those 20 years that you have been watching people use the GNU tool.  In 
2001, Paul Jarc invented a fairly simple notation for such things; 
providing what is effectively a mini-language, made out of chaining 
programs and using environment variables for variables, with |add|, 
|sub|, |min|, |max|, |statfile|, and |match| operators.


* http://code.dogmap.org/runwhen/example/

* http://code.dogmap.org/runwhen/stamp-fmt/

* http://code.dogmap.org/runwhen/

Xe even went through the second-system-effect process of not liking the 
first way that xe implemented it.


* http://code.dogmap.org/runwhen/caldelay/

Leаh Neukirchen took the old |caldelay| idea, and turned environment 
variables into command-line options.


* https://github.com/chneukirchen/snooze

Although |add n d1s now1s match $now1s ,H=2,M=30 wake statfile started 
add $MTAI64N d1H earliest ||max $wake $earliest wake| (which is 
effectively a prefix notation which in an infix form would be something 
like |$now1s := ||now add d1s ; $||wake := ||$now1s findnextmatching 
H=2,M=30 ; $||MTAI64N||:= timestampof started ; $||earliest :=||$MTAI64N 
add d1H ; $||wake :=||$wake max $earliest|) is more along the lines that 
you were writing about earlier.  (One can imagine a pair of date 
calculator tools akin to |dc| and |bc| that understand the prefix and 
infix forms.)

Re: Frustration over Debian naming

[Jonathan de Boyne Pollard]

rhkramer:

Intentionally cross posted. Aside: For those on the debian-user lists, 
the thread came from the debian-backports list, but my frustration 
should probably be expressed more to the debian-user list (or 
debian-developer list, assuming there is such a list (to which I am 
not subscribed). [...]


But the various names and use of those names gets very frustrating for 
me, and I suspect I am not the only one. The numbered versions, the 
Toy Story names, and then the testing, stable, old stable, old old 
stable is just frustrating.


Tangentially to that, it seems that someone needs to pick up the dropped 
baton and update the pictures.


* 
http://wiki.lib.sun.ac.za/images/thumb/a/aa/Timelinededebian.png/800px-Timelinededebian.png


* 
http://blog.admin-linux.org/wp-content/uploads/2012/01/infographic_debian_history-en-v081.png


* http://doc.callmematthi.eu/pictures/Understanding_Debian.png

* https://i.stack.imgur.com/nLXu9.jpg

* 
https://bsdmag.org/wp-content/uploads/2016/08/infographic_debian-v2.1.en_.png

nosh version 1.36

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.36 .

 *

   http://jdebp.eu./Softwares/nosh/

 *

   
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project

 *

   http://jdebp.info./Softwares/nosh/


   More Java tools

This release comes with the |find-default-jvm| and |find-matching-jvm| 
tools, which will set up the |JAVA_HOME| environment variable to point 
to a default/matching JVM directory, using the FreeBSD/TrueOS and Debian 
conventions for locating JVM directories.  To match these, 
|convert-systemd-units| now recognizes |JVMDefault|, |JVMVersion|, 
|JVMOperatingSystem|, and |JVMManufacturer| extensions to the systemd 
unit file format.



   Tool improvements

|convert-systemd-units| now recognizes a |MachineEnvironment| extension 
to the systemd unit file format, which controls the generation of an 
invocation of |machineenv|.  It also now recognizes and translates 
|RDMAHCAHandlesMax| and |RDMAHCAObjectsMax| settings.


The |unshare| command now has flags for specifying process ID and user 
ID namespaces on Linux.


The |setup-machine-id| command now correctly falls back to the old D-Bus 
files on FreeBSD, which it had not been doing because of a bug.



   New system management features

In support of an initiative by Warner Losh, there is support for power 
cycling via hardware and a kernel that support it.


The system manager treats |SIGRTMIN+6|, unused in the systemd system, as 
a request to invoke a new |powercycle| service bundle; and 
|SIGRTMIN+16|, similarly unused, as the underlying actual powercycle 
request, which it translates to either |RB_POWERCYCLE| if it is present 
in the C library headers, or |RB_AUTOBOOT| if it is not. There is a new 
|system-control powercycle| subcommand, which defaults to sending these 
signals.


Note that the binary packages are currently built on a system that lacks 
|RB_POWERCYCLE| in the C library.


The compatibility |shutdown|, |reboot|, |halt|, and |poweroff| commands 
all now sport a new |-c|/|--powercycle| option.  There are new 
|fastpowercycle| and |powercycle| commands.  The |system-control init| 
subcommand now sports a new |c|/|C| argument, by analogy to |h|/|H|. And 
this is of course thus reflected automatically in the compatibility 
|telinit| command and the |initctl-read| server.



   Service bundles

Fixing an oversight in 1.35, the per-user |dbus| services are now 
renamed to |dbus-daemon| too.


There are a few more service bundles, including ones for |jenkins|, 
|apacheds|, |udisks2|, and |ndppd|.


The |linux-utmp| service bundle has been retired, in favour of a unified 
|utx| service bundle, which was previously FreeBSD-only, that operates 
across platforms.  In support of this, there is a new 
|login-update-utmpx| command, and a new |freebsd-shims| package that 
aliases that to the |utx| command on non-FreeBSD platforms.

The new normal of logging

[Jonathan de Boyne Pollard]

Roberto C. Sánchez:

Is this the new normal, for things to get captured in some systemd log 
[...]?



* https://unix.stackexchange.com/a/294206/5132 Yes.

Upgrade from jessie to strech wants to bloat by system

[Jonathan de Boyne Pollard]

  
  

Urs Thuermann:

  I see that some new versions of packages are installed without
the old versions being removed, although they are marked as
automatically installed, e.g. Linux kernel, clang, llvm, and
some others. For example
  
# aptitude search "~i clang"
  i   clang - C, C++ and Objective-C compiler (LLVM based)
  i A clang-3.5 - C, C++ and Objective-C compiler (LLVM based)
  i A libclang-common-3.5-dev   - clang library - Common development package
  i A libclang1-3.5 - C interface to the clang library

   and aptitude full-upgrade will install clang-3.8 but not
remove clang-3.5.

Ben Finney:


  
  That shows the ‘clang’ package is *not* marked auto-installed.

M. Thuermann did explicitly say clang-3.5, not clang.
  

nosh version 1.35

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.35 .

 *

   http://jdebp.eu./Softwares/nosh/

 *

   
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project

 *

   http://jdebp.info./Softwares/nosh/


   Networking

As I mentioned a week or so ago, the external configuration import 
subsystem now converts a Debian-style /etc/network/interfaces 
configuration file, via rc.conf settings, into the native networking 
subsystem.


There is also a whole new /Networking/ chapter in the /nosh Guide/, 
which explains this and several other things, including how Plug and 
Play integration interoperates with the networking services and what the 
native networking subsystem encompasses, to the level of what service 
does what and to what purpose.


Work on the Plug and Play integration is on-going, and I hope to have 
yet more for this, and indeed for other parts of the networking 
subsystem, in version 1.36.



   Packages

There are some Debian packages that declare that they need the logrotate 
package, even though they do not when run under nosh service 
management.  For their benefit there is now a nosh-logrotate-shims 
Debian package that is simply a dummy package that satisfies this need 
without setting up a spurious and unnecessary logrotate system.



   Service bundles

There are a few more service bundles, including ones for sysstat and 
elasticsearch.  The existing service bundles for things such as unbound, 
clamav, and freshclam have been augmented and fixed in response to user 
feedback.  And a bug that incorrectly resulted in the ldconfig service 
being disabled has been fixed.


The dbus services, the system-wide one and the per-user one(s), have 
been renamed to dbus-daemon.  This is because of the existence of a 
dbus-broker service bundle.  This is a placeholder for if the 
dbus-broker people ever fix it so that it works. dbus-broker does not 
provide a working system right now.  It is currently not possible to 
substitute dbus-broker for dbus-daemon on non-systemd systems, because 
dbus-broker is very tightly tied in to systemd's idiosyncratic D-Bus 
control interface.  It /only/ speaks the systemd-specific protocol, and 
knows no other way of stopping and starting services, not even the 
service command.  (In contrast dbus-daemon can still be configured to 
demand-start services using simple service management commands 
.)

Archnosh 1.35 networking

[Jonathan de Boyne Pollard]

Thomas:


[...] the new networking documentation [...]

This will benefit a general readership, as well as you looking towards 
Archnosh 1.35.


When you upgrade to 1.35, there will be two ways of configuring things.  
You can either write a Debian-style /etc/network/interfaces file, or you 
can employ a FreeBSD-like rc.conf.  Both styles will work on FreeBSD, 
TrueOS, Debian, and (I hope) Arch. The former you will find is 
translated into the latter.  For more detail on that translation 
process, see the new doco.  Here is an example from one of my machines.


jdebp % cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

auto lo
iface lo inet loopback
iface lo inet static
address 127.53.53.1
netmask 255.0.0.0
scope host
iface lo inet6 loopback
iface lo inet6 static
address ::2/128
scope host
allow-auto eth1
iface eth1 inet dhcp
iface eth1 inet6 auto
allow-auto rename2
iface rename2 inet dhcp
iface rename2 inet6 auto

jdebp % sed -ne '/etc.network.interfaces/,/console-setup:/p' 
/etc/system-control/convert/rc.conf
# Converted from /etc/network/interfaces:
network_interfaces="eth1 rename2 lo "
ifconfig_eth1="AUTO DHCP inet  "
ifconfig_rename2="AUTO DHCP inet  "
ifconfig_lo="AUTO inet  127.0.0.1 "
ifconfig_lo_ipv6="inet6  ::1 "
ifconfig_lo_aliases="inet 127.53.53.1 netmask 255.0.0.0
inet6 ::2/128"
# Converted from /etc/default/console-setup:
jdebp %

dhcp restart with bad config

[Jonathan de Boyne Pollard]

Bonno Bloksma:

There is the strange fact that it seems the config is tested twice but 
I guess systemd will try to start a service twice before giving up.


I recommend less guessing and more reading your own posts.  (-: You 
yourself posted the very script fragment where /the script itself/ runs 
the test command twice:



test_config()
{
 if ! /usr/sbin/dhcpd -t $OPTIONS -q -cf "$DHCPD_CONF" > /dev/null 
2>&1; then
 echo "dhcpd self-test failed. Please fix $DHCPD_CONF."
 echo "The error was: "
 /usr/sbin/dhcpd -t $OPTIONS -cf "$DHCPD_CONF"
 exit 1
 fi
}


See where that runs |/usr/sbin/dhcpd| in test mode twice?  The first 
time, dhcpd writes the error message to the syslog; the second time 
|dhcpd| writes the error message to its standard error.  Both lots of 
output end up in the journal.


From the LSB: prefix to the service name in the very log output that 
you posted, we can deduce that systemd is running your van Smoorenburg 
|rc| script as a service, wrapping it in a nonce service unit 
.  The test performed by 
the van Smoorenburg |rc| script is considered to /be a part of your 
service/.  By the time that the script is running, and executing the 
startup test, systemd thinks that your service is already running.  The 
stop and start actions of systemd encompass the script as a whole, and 
operate outwith the configuration validation test, not within it.


Put another way: There is no customizable mechanism to make the very 
execution of the start, stop, and restart commands in systemd dependent 
from first testing some arbitrary service-specific condition.  There's 
no way to tell systemd "only actually execute the restart command at all 
if this shell script first returns true".  When running restart, systemd 
will stop your service, start it again, and the test in the script will 
/only then/ run as part of your service's initialization.


The best that you have are mechanisms that cause a startup to abort, by 
failing an ExecStartPre command.  But for those you must actually write 
a proper service unit file. |systemd-sysv-generator| employs a 
one-size-fits-all approach, and will not generate such service-specific 
special-case stuff in the nonce units that it generates for van 
Smoorenburg |rc| scripts.  You need a bona fide human being to actually 
write a service unit file.  Even then, that is not enough.  A restart 
will still stop the service /before/ the ExecStartPre tests are run, and 
you won't get what you want. restart is stop /then/ start.

Re: systemd says "org.freedesktop.systemd1.TransactionIsDestructive"

[Jonathan de Boyne Pollard]

Dave Sherohman:

The mention of freedesktop in one of the messages suggests that this 
may be somehow X/GUI related,


No, it does not.  That is not the only place where one finds such 
names.  Or, rather, the mechanism that uses such names is not only used 
for graphical user interfaces.


It is, of course, D-Bus.  The |systemd-logind| dæmon is communicating 
with the |systemd| dæmon, in order to start a service, via its D-Bus 
interface .  And 
the |org.freedesktop.systemd1.TransactionIsDestructive| error code is 
what the |systemd| dæmon is communicating back.  You are witnessing the 
undocumented interface between |systemd-logind| and |systemd|.


The problem that it indicates is that when |systemd| is trying to start 
the service, which is actually a so-called /scope/ named 
|session-11179.scope|, it has encountered a contradiction.  As the user 
manual explains, when systemd comes to start a service, it breaks it 
down into a collection of /jobs/, which are individual actions to take 
in order to achieve the overall goal 
.  What has happened here 
is that the set of jobs necessary to start |session-11179.scope| is 
self-contradictory, or contradicts existing jobs running at the time.  
It involves both starting/checking/restarting/reloading something and 
stopping it, simultaneously.


The people who hit this at shutdown have systems with a similar 
configuration problem to yours.  On yours and theirs, there's some 
configured contradiction, a unit that both is wanted by and conflicts 
with another unit; somewhere.  That might be down a long chain connected 
from the unit that you think that you are dealing with.  Or there's a 
contradiction with something else executing concurrently within |systemd|.


The scope unit is not something that you can do without; if you are 
doing things within login sessions, that is.  As you note, the failure 
to start it stops |su| from working. Scope units are used by 
|systemd-logind| to create /user-mode//login sessions/ 
.  It 
arranges, in conjunction with PAM extension modules, that all of the 
processes inside such a login session run within such a scope.  It uses 
the scope to place resource usage constraints upon the login session, 
such as a maximum number of processes.


Unfortunately, you have a hard task ahead. You can run things like 
|systemctl list-jobs|, but it is a good bet that what you are seeing is 
timing-dependent because it is a contradiction between two concurrent 
things.  You will likely find that you have to run |systemctl list-jobs| 
at just the right time, too.


That said, it does sound like, from the scant description given, you are 
mis-using |su|. Do not abuse |su| to drop privileges 
, from 
|root| to |nobody|.  There are proper tools for the job of dropping 
privileges, which do not involve PAM and which will thus not hit this 
problem.  Moreover: do not abuse |nobody| for running dæmons 
, if you are 
doing that.  Set up a proper rôle account.  And, indeed, give the cron 
job (whatever it is) directly to that rôle account's |crontab|.

Re: Weird shell script behavior in a cron job

[Jonathan de Boyne Pollard]

James H. H. Lampert:

Could it be that |cron| is running it an entirely different shell, 
that doesn't understand the |if| statement?


Despite what others have said, the answer to this question is no.  
Whilst you /are/ running two different shells, the problem is not the 
|if| statement.  Both of those shells understand that |if| statement.  
The difference between the shells involves the fact that you have 
assumed a particular exit status for the |cd| command for non-existent 
directories.  That's the exit status that the |cd| command results in, 
in one of your shells.  But it is not the exit status that results in 
the other.


Ironically, you are using the |[| command /anyway/, and that command has 
a direct method, its |-d| operator, for testing for the non-existence of 
a directory.  So you are going around the houses a bit in order to 
achieve what you could be achieving directly, and portably (without 
assumptions about exit statuses), with the |[| command itself.

Re: obsolete wiki

[Jonathan de Boyne Pollard]

rhkra...@gmail.com:


Well, even a vague note on the page something like:

"Some of this seems to be out of date with the advent of systemd and 
its adoption in Debian starting with version n.n (). 
If you can contribute anything more to this story, please do."


...would be a start.

That sort of editing, sticking little sentences in without regard to the 
article as a whole, or even the immediately surrounding paragraphs, is 
very prevalent at Wikipedia and is one of the major causes of pages 
degrading over time. It does not work well.


https://unix.stackexchange.com/questions/388427/ at Stack Exchange is an 
example of the effect of such things. The relevant wiki page was 
annotated with precisely that sort of thing, 
https://wiki.debian.org/motd?action=diff&rev1=15&rev2=16, placing a 
paragraph at the top that said that the rest of the page was out of date 
as of Debian 7. You can see from the Stack Exchange question the 
confusion that this causes for readers. Ironically, the wiki page 
answers the question in a single sentence. But the answer for what 
Debian does nowadays is buried for the reader under a morass of what 
Debian used to do, and did not get seen at all, resulting in the person 
coming to Stack Exchange in the first place.

No ifconfig

[Jonathan de Boyne Pollard]

Eike Lantzsch:


Yes, I ask myself why this isn't possible on Linux:

ifconfig enp3s0 inet alias 192.168.12.206 netmask 255.255.255.0

while it is perfectly possible on OpenBSD (with the correct device of 
course).



It's possible if you spell it |inet add| instead of |inet alias|.  (-:

No ifconfig

[Jonathan de Boyne Pollard]

Christian Seiler:

From my personal experience, the following two things are features I'm 
actually using regularly and that don't work with it:


1.

IPv6 doesn't really work properly (as explained elsewhere by other
people in this thread)

2.

Can't add multiple IP addresses to the same interface and (worse)
even if multiple IP addresses are assigned to the same interfaces
it only shows the primary address

(2) is really bad, especially the part where it does not show all of 
the IPs that were assigned by other tools, for example NetworkManager, 
or Debian's own |ifupdown| via |/etc/network/interfaces|.




Your second point is a conflation of two things.  One is right, but the 
other is wrong.  Here is what actually happens.  Starting with this basis:



jdebp % ifconfig lo|head -n 4
loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   inet6 addr: ::2/128 Scope:Compat
jdebp % ip address show lo|fgrep -A 1 inet
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet 127.53.53.1/8 scope host secondary lo:0
valid_lft forever preferred_lft forever
 inet6 ::2/128 scope global
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
jdebp %


|ifconfig| cannot see additional addresses assigned by the likes of |ip| 
in its simplest fashion, as here:



jdebp % sudo ip address add 127.53.0.1 dev lo
jdebp % ifconfig lo|head -n 4
loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   inet6 addr: ::2/128 Scope:Compat
jdebp % ip address show lo|fgrep -A 1 inet
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet 127.53.0.1/32 scope host lo
valid_lft forever preferred_lft forever
 inet 127.53.53.1/8 scope host secondary lo:0
valid_lft forever preferred_lft forever
 inet6 ::2/128 scope global
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
jdebp %


But it most definitely /can/ assign multiple IP addresses to a single 
interface, and these will be reported as such by |ip| even though 
|ifconfig| shows them differently:



jdebp % sudo ifconfig lo inet add 127.53.0.2
jdebp % ifconfig lo|head -n 4
loLink encap:Local Loopback
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   inet6 addr: ::2/128 Scope:Compat
jdebp % ifconfig lo:0|head -n 2
lo:0  Link encap:Local Loopback
   inet addr:127.53.0.2  Mask:255.0.0.0
jdebp % ip address show lo|fgrep -A 1 inet
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet 127.53.0.1/32 scope host lo
valid_lft forever preferred_lft forever
 inet 127.53.53.1/8 scope host secondary lo:0
valid_lft forever preferred_lft forever
 inet 127.53.0.2/8 scope host secondary lo:1
valid_lft forever preferred_lft forever
 inet6 ::2/128 scope global
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
jdebp %


Moreover, one /can/ add multiple IP addresses to an interface with |ip| 
in such a way that |ifconfig| sees them, by assigning labels:



jdebp % sudo ip address del 127.53.0.1/32 dev lo
jdebp % sudo ip address add 127.53.0.1 dev lo label lo:2
jdebp % ifconfig lo:2|head -n 2
lo:2  Link encap:Local Loopback
   inet addr:127.53.0.1  Mask:255.255.255.255
jdebp %


One interesting tidbit in the aforegiven:  The network mask inference 
calculation differs. |ip| inferred 127.53.0.1/32 whereas |ifconfig| 
inferred 127.53.0.2/8.

No ifconfig [Was: no /etc/inittab]

[Jonathan de Boyne Pollard]

Greg Wooledge:



wooledg:~$ ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
mode DEFAULT group default qlen 1000
 link/ether a0:8c:fd:c3:89:e0 brd ff:ff:ff:ff:ff:ff

Parsing the interface names out of THAT is significantly harder.



In support of my earlier point that some /other/ people /did/ make 
modern |ifconfig| usable in such ways:

JdeBP % ifconfig -l
bge0 bge1 lo0 tun0
JdeBP %


Here's something from a script of mine:

list_available_network_interfaces() {
 case "`uname`" in
 Linux)  /bin/ls /sys/class/net ;;
 *)  ifconfig -l ;;
 esac
}


(Note that this is as loose as it is because I'm only targetting 
Linux-based operating systems and the BSDs so far here.  Also note that 
this breaks on OpenBSD which does not have the |-l| option to 
|ifconfig|.  Fixing that is on the to-do list.)

obsolete wiki (no /etc/inittab)

[Jonathan de Boyne Pollard]

Greg Wooledge:


Gene's copy/paste was crude, but his point was essentially valid:



No, it was not. I remind you of xyr point which was:


Gene Heskett:


So if you call it widely publicized it fails that definition AFAIAC.



That I pointed to 9 different copies, including copies on Debian's own 
manual pages WWW site for Debian Wheezy as well as in prominent 
locations for such information (including linux.die.net, man7.org, and 
Stack Exchange), out of the many more copies on the WWW of this 
information, should be ample demonstration that this is *indeed* widely 
publicized.  It has been so widely publicized that it has even managed 
to filter through into books, years since.  Christopher Negus's _Linux 
Bible_ points it out, for example, and that was published back in 2015.


Subsequent backpedalling on this claim of not being widely publicized 
has been to the effect that the wide dissemination of this information 
did not reach Gene Heskett, which is really not a criterion for being 
widely publicized, and that somehow, the manual pages that I pointed to 
were not "Wheezy approved", when clearly they are right there on 
Debian's own manual pages WWW site for Debian 7 (the string "wheezy" 
even being in the two URLs given).


The simple truth is that the several independent groups of people who 
all made these particular changes *did* document them and publicize 
them.  Sadly, there are things far more deserving of the "They didn't 
tell anyone about this!" accusation; the desuetude of /etc/inittab, 
which we've been warned about for over ten years, is not however one of 
them.

obsolete wiki (was: no /etc/inittab)

[Jonathan de Boyne Pollard]

Felix Miata:

The problem with software documentation wikis is the people in best 
position to know what they should contain have no incentive to do the 
update work. To write useful docs requires knowledge what should be in 
them. That knowledge is mostly possessed by those writing and changing 
code, those who /caused/ the need to update docs.



Brian:


Knowledge is confined to those who know what they are doing? They are 
the ones in charge? It is not for us ordinary mortals to spread or 
interpret it? Some politians and priests are with you. Disseminating 
knowledge is only for the few.


That is a straw man, and very clearly (to at least this reader) not what 
M. Miata wrote at all.

Re: How does one create virtual ethernet devices with modern tools on Debian 8 (jessie)?

[Jonathan de Boyne Pollard]

Tom Browder:


   # added alias IPv4s:
   up   ip addr add 142.54.186.3/29 dev $IFACE label $IFACE:0
   down ip addr del 142.54.186.3/29 dev $IFACE label $IFACE:0


Ironically, the "modern tools" aspect is the thing that you are in fact 
aiming to eliminate here. |/etc/network/interfaces| is best treated as 
an entirely descriptive mechanism, with as little imperative stuff in it 
as can be arranged.  Here, you are getting rid of the imperative 
explicit invocations of the |ip| command, the "modern tool" as you 
mention, and replacing them with the descriptive "stanzas" that 
|/etc/network/interfaces| /already has/ as a mechanism for 
non-imperatively describing multiple IPv4/IPv6 addresses on a single 
|eth0| interface.


|ifup| and |ifdown| are best thought of as translators, as their manual 
page implies.  They take what is in |/etc/network/interfaces| and 
translate it into the necessary sequences of imperative commands for 
actually doing the job, which they run under the covers. Those 
underlying commands can include |bootpc|, |avahi-autoipd|, 
|settle-dad.sh|, |pon|, |poff|, |wvdial|, |dhclient|, |dhclient3|, 
|pump|, |udhcpc|, |dhcpd|, |kill|, |ip|, and (sic!) |ifconfig|, all 
invoked with various parameters calculated from the 
|/etc/network/interfaces| description.


They aren't the only translators for that file.  For example, here's 
what happens when one runs your proposed non-imperative 
|/etc/network/interfaces| (with the typing errors mentioned elsewhere 
cleaned up) through mine, which translates from that description 
 into 
(roughly) the |rc.conf| configuration format for FreeBSD/TrueOS 
:



JdeBP % sudo redo -C /etc/system-control/convert/ rc.conf
Password:
redo: INFO: rc.conf: Redone.
JdeBP % sed -ne '/etc.network.interfaces/,/sysrc:/p' 
/etc/system-control/convert/rc.conf
# Converted from /etc/network/interfaces:
network_interfaces="lo eth0 "
ifconfig_lo="AUTO inet  127.0.0.1 "
ifconfig_eth0="AUTO inet  142.54.186.2 netmask 255.255.255.248 gateway 142.54.186.1 
"
ifconfig_eth0_ipv6="inet6  2604:4300:a:95::2 netmask ::::: "
ifconfig_eth0_aliases="inet 142.54.186.3
inet 142.54.186.4
inet 142.54.186.5
inet 142.54.186.6
inet6 2604:4300:a:95::3
inet6 2604:4300:a:95::4
inet6 2604:4300:a:95::5
inet6 2604:4300:a:95::6"
# dump by sysrc:
JdeBP %

Systemd: Error when replacing postfix LSB init with postfix.service on Debian 8 (jessie)

[Jonathan de Boyne Pollard]

Sven Hartge:


systemd happily runs "legacy" LSB init scripts

... except when its one-size-fits-all approach does not work, of 
course.  Example:


* https://unix.stackexchange.com/questions/386846/

This is the problem with even Mewburn rc scripts (as I can attest from 
personal experience of writing replacements for an entire Mewburn rc 
system) let alone with van Smoorenburg rc scripts (which are far messier 
than Mewburn rc ones).  One size does not fit all.  One really is not 
going to ever get a backwards-compatibility mechanism that copes with 
all such scripts in the general case "happily".

Systemd: Error when replacing postfix LSB init with postfix.service on Debian 8 (jessie)

[Jonathan de Boyne Pollard]

Tom Browder:


# systemctl enable postfix # systemctl daemon-reload



Minor note: enable incorporates a daemon-reload.

Re: No ifconfig

[Jonathan de Boyne Pollard]

Erik Christiansen:

Gene, ifconfig is SysV flavoured, so not favoured on the Systemd 
journey, AIUI.




van Smoorenburg init and systemd actually have nothing whatsoever to do 
with it.  ifconfig uses one Linux API for sending information to and 
from the kernel, ip uses a different Linux API.  Ironically, the 
net-tools package is completely Linux-specific *anyway*, so the usual 
argument that ifconfig couldn't be changed to use the other API, because 
it has to remain portable, does not hold any water.


That said, one of the things that in practice ifconfig falls down on in 
real world use, where most of the use cases are fairly conventional and 
humdrum, is in IPV6 support:



root # ifconfig lo inet6 ::1

Don't know how to set addresses for family 10.

root #



This is actually a fairly trivial oversight in a case statement in the 
code, rather than a fundamental design or implementation problem, 
though.  It doesn't even need the other API.

Re: obsolete wiki (no /etc/inittab)

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:

Furthermore: In this *particular* regard, the developer-provided doco 
actually *is* clear. The upstart manual page for inittab has been 
warning that the file is obsolete for over ten years, and that manual 
page is copied all over the WWW making it fairly easy to come across. 
(Examples: https://linux.die.net/man/5/inittab 
https://askubuntu.com/questions/34308/ 
https://serverfault.com/questions/147430/ 
http://manpages.ubuntu.com/manpages/precise/man5/inittab.5.html)


The systemd people have not explicitly documented inittab, as the 
upstart people did, although they have explicitly documented run 
levels as "obsolete" in the systemd manual page for runlevel. This, 
too, has been copied around the WWW, albeit somewhat less. (Examples: 
https://manpages.debian.org/stretch/systemd-sysv/runlevel.8.en.html 
http://man7.org/linux/man-pages/man8/runlevel.8.html 
https://www.mankier.com/8/runlevel)




Gene Heskett:

Its becoming obsolete is NOT mentioned in my wheezy approved and 
supplied man page for it, I just read it this instant. So if you call 
it widely publicized it fails that definition AFAIAC.




Debian 7 has those very manual pages:


* https://manpages.debian.org/wheezy/upstart/inittab.5.en.html


* https://manpages.debian.org/wheezy/systemd-sysv/runlevel.8.en.html

Re: no /etc/inittab

[Jonathan de Boyne Pollard]

Joe:

Stretch? Systemd was default init for Jessie, the previous stable. 
Worse, an upgrade of Wheezy to Jessie would actually change the init 
system used, thus breaking almost every Debian server in the world.




Nicolas George:


I must be lucky, none of the servers that I handle broke because of that.



You are. Every single Debian 7 system with systemd that I upgraded to 
Debian 8 hit Debian Bug #774153, meaning that the upgrades did not 
complete unattended.

Re: obsolete wiki (no /etc/inittab)

[Jonathan de Boyne Pollard]

Felix Miata:

What's needed is incentive for code creators to simultaneously 
document, with ample examples that man pages usually omit, even if 
it's only in formal, non-wikified docs that wikis can point to.




Gene Heskett:

It should be an iron-clad rule that a developer submitting his itch 
scratcher code to a distribution must be subscribed to that 
distributions user list BEFORE he can commit.




That does not work and does not scale.  What would work is what M. Miata 
said, which is to inculcate in software developers a culture of always 
providing doco with the software, and regarding the job as not complete 
unless there is doco.


That said, an obscure page (which people even in this thread were hard 
pressed to find) on someone else's wiki does not really count.  
Furthermore: In this *particular* regard, the developer-provided doco 
actually *is* clear.  The upstart manual page for inittab has been 
warning that the file is obsolete for over ten years, and that manual 
page is copied all over the WWW making it fairly easy to come across.  
(Examples: https://linux.die.net/man/5/inittab 
https://askubuntu.com/questions/34308/ 
https://serverfault.com/questions/147430/ 
http://manpages.ubuntu.com/manpages/precise/man5/inittab.5.html)


The systemd people have not explicitly documented inittab, as the 
upstart people did, although they have explicitly documented run levels 
as "obsolete" in the systemd manual page for runlevel. This, too, has 
been copied around the WWW, albeit somewhat less. (Examples: 
https://manpages.debian.org/stretch/systemd-sysv/runlevel.8.en.html 
http://man7.org/linux/man-pages/man8/runlevel.8.html 
https://www.mankier.com/8/runlevel)


I for one have been attempting spreading the word about inittab, too.

* http://jdebp.eu./FGA/inittab-is-history.html

* http://jdebp.eu./Softwares/nosh/guide/introduction.html

* https://unix.stackexchange.com/a/248313/5132

* https://unix.stackexchange.com/a/196197/5132

* https://askubuntu.com/a/834323/43344

* http://jdebp.eu./Softwares/nosh/guide/runlevel.html

In this particular case, one cannot really level the charge of 
developers not documenting this.  It is amply documented, by developers 
of multiple projects, in their manual pages in their handbooks/guides 
and on their WWW sites, for over a decade.  The deficiencies of Debian's 
own wiki cannot legitimately be laid at the feet of the developers of 
the various softwares.


One such developer even tried to donate to you an update to the Debian 
Policy Manual that explained both /etc/inittab (in section 9.3.4) and 
the changes that arrived in 2014, to replace your woefully outdated one:


* http://jdebp.eu./Proposals/DebianPolicy/

Re: no /etc/inittab

[Jonathan de Boyne Pollard]

Pierre Frenkiel:

I discovered recently, after re-installing my system with the Debian 
9.1 kde live dvd, that the /etc/inittab is no more present, although 
all the documentation I found still mentions it,




Have a frequently given answer that tells you otherwise.  (-:

* http://jdebp.eu./FGA/inittab-is-history.html

Re: No ifconfig

[Jonathan de Boyne Pollard]

Glenn English:

I've written many scripts over the years, using ifconfig and others, 
and having everything broken now is a major PITA.


I very much agree that sysV init and those old commands were a mess, 
especially with the introduction of ipv6. But I'd have more inclined 
to fix what was there than to replace it with commands that return 
gibberish and kill so many scripts so many people have written.




That is, in fact, what the BSD people did.  On FreeBSD and OpenBSD, for 
examples, modern ifconfig has fully functional IPv6 capability, with 
parameters like (to pick just some at random) eui64, prefixlen, 
auto_linklocal, autoconfprivacy, defaultif, and ifdisabled.

No ifconfig

[Jonathan de Boyne Pollard]

Henrique de Moraes Holschuh:
[...] and the only reason we had to keep it around by default [...] 
was broken by GNU upstream when it took ifconfig out of the bit-rot 
pit hell and started maintaining it again.


net-tools is not a GNU Software package.

* https://sourceforge.net/projects/net-tools/

* https://www.gnu.org/software/software.html

Re: W: Failed to fetch [..] The following signatures were invalid: [..]

[Jonathan de Boyne Pollard]

Adam Cecile:

Since I upgraded to Stretch I get the following warning when running 
apt update:


W: Failed to fetch 
http://archive.cloudera.com/cdh5/debian/jessie/amd64/cdh/dists/jessie-cdh5/InRelease The 
following signatures were 
invalid:F36A89E33CC1BD0F71079007327574EE02A818DD




What the people at Cloudera want is 
https://unix.stackexchange.com/questions/387053/ .  What you need is to 
tell the people at Cloudera that.


The Cloudera people also need to update their instructions to cover 
Debian 9.  Just duplicating the Debian 8 and 7 instructions is not 
really right, note.

Re: How to change default umask in Stretch?

[Jonathan de Boyne Pollard]

Henrique de Moraes Holschuh: > Note that the ideal implementation would 
be to inherit the umask [...] Jonathan de Boyne Pollard: > Actually, the 
ideal implementation from the GNOME point of view would be for > these 
programs to pass the umask from the client process to the server, just > 
like they pass open file handles, the working directory, environment > 
variables (including DISPLAY), and the arguments vector. > > 
* https://github.com/GNOME/gnome-terminal/blob/52f32f962a5ed34f8c31042f2f8276dc1710cc99/src/terminal.c#L317 
> 
* https://github.com/GNOME/glib/blob/b51a0e7c63313ecfc0c6bbb9f2a8d99f193e51ea/gio/gapplication.c#L923 
Henrique de Moraes Holschuh: > You'd have to always indirectly start an 
intermediate "gnome launcher" > thing (instead of the real program) that 
sets up the environment, then > exec the real program for that to work. 
No, that would not be necessary at all. Think about how GNOME Terminal 
and GNOME Editor work. As I said: These are already passing a whole 
bunch of process state from the client to the server, in order to 
preserve things like the apparent semantics of GNOME Terminal windows 
"inheriting" the working directories of the invoking clients, when in 
reality there is no inheritance from those client processes going on at 
all. This would be just one more such item of process state.

Re: How to change default umask in Stretch?

[Jonathan de Boyne Pollard]

Henrique de Moraes Holschuh:


Note that the ideal implementation would be to inherit the umask [...]



Actually, the ideal implementation from the GNOME point of view would be 
for these programs to pass the umask from the client process to the 
server, just like they pass open file handles, the working directory, 
environment variables (including DISPLAY), and the arguments vector.


* 
https://github.com/GNOME/gnome-terminal/blob/52f32f962a5ed34f8c31042f2f8276dc1710cc99/src/terminal.c#L317


* 
https://github.com/GNOME/glib/blob/b51a0e7c63313ecfc0c6bbb9f2a8d99f193e51ea/gio/gapplication.c#L923

Re: How to change default umask in Stretch?

[Jonathan de Boyne Pollard]

Greg Wooledge:


It's beginning to sound like GNOME applications aren't even launched 
by GNOME at all, but rather by systemd/dbus. Somehow.




GNOME Editor and other GIO applications work like how 16-bit Windows 
applications used to work.


GNOME Terminal goes yet farther and not even the first instance is the 
originally invoked process.  All instances, even the first, are 
"bus-activated".  Depending from whether there is a per-user instance of 
systemd or not, there may be a further level of indirection.


Of course, in the case where "bus activation" is configured to at least 
pass things over to some proper per-user service management, the place 
to set the ulimit for the likes of GNOME Terminal is in the per-user 
service definition for GNOME Terminal server.  With the nosh per-user 
service mangement, this would be the 
$HOME/.config/service-bundles/services/gnome-terminal-server/service/run 
program.  With systemd per-user service management this would be a 
$HOME/.config/systemd/gnome-terminal-server.service.d/ulimit.conf 
override for /usr/lib/systemd/user/gnome-terminal-server.service .


With nosh per-user service management, there is a 
$HOME/.config/service-bundles/services/gedit service, which one can 
start before attempting to run the first GNOME Editor instance; which 
would permit one to place ulimit and suchlike modifications in 
$HOME/.config/service-bundles/services/gedit/service/run .  Vanilla 
GNOME Editor does not attempt to plumb into systemd's per-user service 
management, as GNOME Terminal does; so there is no systemd equivalent here.


* https://news.ycombinator.com/item?id=13056252

* https://unix.stackexchange.com/a/323700/5132

* https://unix.stackexchange.com/questions/201900/

* 
http://jdebp.info./Softwares/nosh/avoid-dbus-bus-activation.html#InheritedLimits


* http://jdebp.info./Softwares/nosh/guide/per-user-dbus-demand-start.html

djbwares version 6

[Jonathan de Boyne Pollard]

djbwares is now at version 6.

* http://jdebp.eu./Softwares/djbwares/
* http://jdebp.info./Softwares/djbwares/

The main changes here are in dnscache and ftpd.

dnscache now has a built-in  resource record for localhost, like it 
already had a built-in A resource record.  I've slightly improved the 
way that it caches  resource record sets, to match the way that it 
was handling A resource record sets.  And it now caches SOA resource 
records.  There are also some minor improvements to the logging to 
decode SRV, A, and  records rather than print them in raw 
hexadecimal format.


The changes to ftpd were motivated by my pointing several WWW browsers 
at a publicfile FTP site and discovering that the WWW browsers adhere to 
the RFCs far less than they used to at the turn of the century.  You can 
read some of the saddening discoveries in the Hall of Shame.  I have 
enhanced publicfile ftpd to support OPTS, FEAT, SIZE, EPSV, and HOST; to 
interoperate better with some faulty FTP ALGs that cannot cope with an 
FTP server that one does not need to log in to; to interoperate better 
with some faulty WWW browsers that misuse CWD as a type testing 
mechanism; and to log things more clearly in order to diagnose such 
faults from server logs.  HOST support means that ftpd supports virtual 
hosting on FTP, which is explained in the manual, although it is hard to 
find any FTP client that employs this.


* http://jdebp.eu./FGA/web-browser-ftp-hall-of-shame.html
* http://jdebp.info./FGA/web-browser-ftp-hall-of-shame.html

A further minor addition is a host command, a subset of the host 
commands from ISC and from KnotDNS that uses the same DNS client library 
from djbdns as all of the other djbdns query tools do.  Of course, the 
conventional djbdns client tools have a simpler syntax and more regular 
behaviours than the host command, and are preferable.  Moreover, the 
subset excludes rarities that djbdns has never supported, such as non-IN 
class queries.

systemd & postgresql - flooding system log

[Jonathan de Boyne Pollard]

Don Armstrong:
> Something like this (untested)

When you do test it (-: you will discover the rather drastic side-effect on all
of the repeated SSH logins of suddenly running them in a completely different
control group with completely different settings.  The systemd PAM hook does
quite a lot of things.  Taking it out does rather more than only the thing that
is wanted here.

Gateway disappears on IPv6

[Jonathan de Boyne Pollard]

Rainer Dorsch:
> for me it looks a little weird that IPv4 gets configured via dhcp and IPv6 is
> a static configuration

It's not, though.  Do not fall into the trap of thinking that because you've had
ubiquitous NAT, stateful DHCP, and the like for IP version 4 that this carries
over into IP version 6.

systemd & postgresql - flooding system log

[Jonathan de Boyne Pollard]

Václav Ovsík:
> How I should get rid of this session management the right way?

I have seen this systemd problem myself.

What is happening is that every time something SSHes in as user postgres,
systemd-logind is starting up a per-user instance of systemd along with with a
whole bunch of per-user socket units (and whatever else you have configured all
per-user service managers to start up); and whenever the SSH session finishes,
systemd-logind is dutifully shutting down that per-user instance.

There's no way to actually turn the per-user instance off, for accounts that
should *never* have per-user service managers.  The best that you can do is
pretty much the opposite and turn it *always on*.  You do this by telling
systemd-logind that the postgres user is a "lingering" user.  There is a
loginctl command for doing so.  Then it will start up the per-user instance of
systemd and leave it running.

(You could also remove the user@.service template outright, which removes
per-user service management for *all* user accounts, including those for real
human beings.  However, this still results in log noise, as the failed attempts
by systemd-logind to start up user@ services on every SSH login will all be
logged.  In the "lingering" case, there is less log noise.)

Of course, the postgres account is most definitely an account which should never
have a per-user service manager.  So, too, are dedicated accounts for things
like (say) Nagios monitoring.

But there's no mechanism for specifying such accounts, or (conversely, and more
usefully given the general ratio of general-purpose use to role accounts) for
specifying the accounts that should have a per-user service manager and saying
that all other accounts should not.  So the best that you can do is be very
aware that everything installed and enabled in /usr/lib/systemd/user is going to
have an instance running with the user access of your postgres account, and be
very careful about what you put in there.  (The gpg-agent package has already
dumped some GPG stuff there and enabled it, notice.)

nosh version 1.34

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.34 .

* http://jdebp.eu./Softwares/nosh/
*
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project
* http://jdebp.info./Softwares/nosh/

Once again, there are a few more service bundles.  The most interesting ones in
this version are perhaps the finish-update and finish-install targets, designed
to be invoked the first bootstrap after an update or install has been done, and
the users target, which is used to auto-start per-user subsystems at bootstrap.
 Several NFS service bundles are now common across operating systems.  And the
OpenVPN service bundles are now split into separate client and server services.

Several minor bugs have been fixed here and there: a duplicated newline in
line-banner that was throwing off publicfile FTP service; a problem with
recordio on FreeBSD/TrueOS; and a problem with attempts to use slashes in
environment variables in service bundle environment directories.

The user-space virtual terminal emulator now implements the Xterm extensions to
DECSCUSR, and the framebuffer realizer can display the resultant cursor shapes.
 This can be made use of by programs such as Neovim.

There are now separate service bundles and nosh-run- packages for running eudev
and systemd-udev, because the two are now significantly divergent.

The various utilities for changing the process environment no longer use the GNU
C library/BSD C library functions for doing so, and so no longer suffer from the
concomitant memory leaks that their manual pages used to warn about.

The convert-systemd-units tool has been slightly enhanced, for the benefit of a
fix that has been made to the per-user gpg-agent service.

The external configuration imports system has been extended.  It now deals with
importing the hostname configuration value, taking that responsibility away from
and simplifying the set-dynamic-hostname utility.  It now imports various Debian
and other kernel virtual terminal settings, from /etc/kbd/config,
/etc/default/console-setup, and /etc/vconsole.conf .  And network configuration
import now can set up services for both dhcpcd and dhclient.
 /etc/system-control/convert/rc.conf now contains more settings on Linux
operating systems as a result, including dhclient_program.

spam to aliases and system accounts

[Jonathan de Boyne Pollard]

Daniel Pocock:
> Do any of the mailers (postfix, exim, etc) provide a convenient way 
> to exclude delivery to system accounts by default, or to exclude 
> these aliases and accounts from receiving mail from external senders? 
> Could anybody share examples of how they do it or pointers to 
> any blogs or wikis with examples? 

The qmail convention of long standing is that an account does not receive mail
in a local mailbox of its own (be that a Maildir in its home directory or an
mboxrd file in /var/spool/mail) if (a) it has UID zero, (b) it has a
non-existent or inaccessible home directory, (c) the account is not the owner of
the home directory, or (d) the account has uppercase letters in its name.

* https://manpages.debian.org/jessie/qmail/qmail-getpw.8.en.html

* http://www.lifewithqmail.org/lwq.html#gotchasexim

So, for examples: mail to ga...@example.com will not be delivered into a mailbox
for the games user because that account is not the owner of /usr/games , its
home directory.  mail to sa...@example.com or usb...@example.com will not be
delivered into a mailbox for the saned or usbmux users because their home
directories, /home/saned and /home/usbmux, do not (normally) exist.

So this is mostly not a packaging problem, and far more a question of whether
your chosen mail system employs a similar convention to that of qmail.  One
could in theory configure exim4 to do the same, but that is not the case in
Debian, where exim4 is merely configured to treat an account as a real person
only unless the account name is the string "root".  Similarly, postfix on Debian
is configured to use the aliases mechanism to filter out rôle accounts, but the
supplied default aliases file in Debian includes almost none of the rôle
accounts employed by Debian packages.

*
https://sources.debian.net/src/exim4/4.89-2/debian/debconf/conf.d/router/900_exim4-config_local_user/

* https://sources.debian.net/src/postfix/3.1.4-4/conf/aliases/

It is to *some* extent a packaging problem inasmuch as some of the rôle user
accounts that some softwares employ are created with seemingly valid home
directories that exist and that they fully own.  The possibly worst offences
here are where people have decided to re-use service runtime directories in /run
as account home directories, given that (with ~/Mailbox or ~/Maildir/ delivery)
this will result in the rôle accounts' junk mail being delivered to a mailbox in
/run .  The avahi account has /var/run/avahi-daemon as its home directory, which
it owns.  Similarly, the irc account has /var/run/ircd as its home directory,
which it owns.  (The hplip account has /var/run/hplip,  and messagebus has
/var/run/dbus; but they do not own those directories.)  Because of this, avahi
and irc satisfy the conventional qmail criteria for being real people user
accounts to whose mailboxes mail should be delivered.

Re: Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Jonathan de Boyne Pollard]

Greg Wooledge:
> Don't even get me started on sshd.service vs. ssh.service.  Do
> you have any idea how hard it is to notice that extra/missing “d”, 
> and figure out why things Simply Do Not Work?

* http://www.mail-archive.com/supervision@list.skarnet.org/msg01486.html

* https://unix.stackexchange.com/a/303302/5132

Yes.

Systemd services (was Re: If Linux Is About Choice, Why Then ...)

[Jonathan de Boyne Pollard]

Greg Wooledge:

> 
> Suppose you want to start DJB's daemontools from a locally created systemd
> unit/service. Here's a file that will do that:
> 

... albeit poorly.  If one wants to run daemontools under systemd, svscanboot is
not the way; svscanboot is a thing of the past
http://jdebp.eu./FGA/inittab-is-history.html#svscanboot , and was a source of
problems long before systemd was invented.


Greg Wooledge:

> 
> (The Linux kernel introduced an entirely new thing called a "cgroup" to
> make this possible. That's how ridiculous self-backgrounding is.)
> 

Control groups are not jobs
http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html ; they were
introduced to do resource limiting, and the systemd developers have actually
complained quite a lot over the years that control groups did not turn out to be
what they thought they were.


Greg Wooledge:

> 
> $ systemctl status daemontools.service
> 
> * daemontools.service – daemontools supervisor
> Loaded: loaded (/etc/systemd/system/daemontools.service; enabled)
> Active: active (running) since Wed 2017-01-11 03:28:47 EST; 2 months 21
> days ago
> Main PID: 529 (svscanboot)
> CGroup: /system.slice/daemontools.service
> |- 529 /bin/sh /command/svscanboot /dev/ttyS0
> |- 531 svscan /service
> 

... and there is svscanboot being a problem again.  Notice how the main PID is
wrong, and the log output from svscan (when there is some) does not go into the
log that systemctl shows below this.


Greg Wooledge:

> 
> if you want to change the behavior of the Debian default getty@ service to
> make it stop clearing the screen all the damned time,
> 

The world wants you to clean your screen
http://unix.stackexchange.com/a/233855/5132 , and this is merely one of the ways
that it makes you do so.

Re: If Linux Is About Choice, Why Then ...

[Jonathan de Boyne Pollard]

Nicolas George:
> The process with PID one is the only immortal process on the system, and
> adopts all orphan processes.

Wrong.  Indeed, it was the systemd people who drove the making it wrong.

* https://unix.stackexchange.com/a/177361/5132

Tiny Utility Toolkit for Tweaking Large Environments

[Jonathan de Boyne Pollard]

Dan Ritter:

> 
> Eventually we'll have to do the work, but the operations staff here has a
> consensus that if we're going to do the work, we might as well go to a system
> that we feel capable of understanding and trusting, something more like
> daemontools. Nosh is being considered.
> 

Having thought about this, I'd do things this way:

You need two new extensions Tuttle:noshService and Tuttle::noshSocket.  Both
work by having INI files in your master configuration area, and they generate
the actual service bundles on the slave systems from those.

Tuttle:noshService ...

* ... has the extension keyword nosh-service.
* ... has two source INI files, ${wibble}.service and cyclog@.service
* ... configures for a rôle by:
1. install_file_copy()s both ${wibble}.service and cyclog@.service to
/var/local/sv/
2. run_command()s system-control convert-systemd-units --local-bundle
--no-systemd-quirks --bundle-root /var/local/sv/ --
/var/local/sv/${wibble}.service
3. run_command()s system-control convert-systemd-units --local-bundle
--no-systemd-quirks --bundle-root /var/local/sv/ --
/var/local/sv/cyclog@${wibble}.service 
4. symbolically links /var/local/sv/${wibble}/log to ../cyclog@${wibble}
5. run_command()s system-control enable -- cyclog@${wibble}.service
 ${wibble}.service
6. run_command()s system-control start --verbose -- cyclog@${wibble}.service
 ${wibble}.service
* ... deconfigures for a rôle by:
1. run_command()s system-control disable -- cyclog@${wibble}.service
 ${wibble}.service
2. run_command()s system-control stop --verbose -- cyclog@${wibble}.service
 ${wibble}.service
3. run_command()s system-control unload_when_stopped -- cyclog@${wibble}.service
 ${wibble}.service
4. remove_file()s both ${wibble}.service and cyclog@.service from /var/local/sv/
5. removes the whole tree at /var/local/sv/${wibble}/ and at
/var/local/sv/cyclog@${wibble}/

Tuttle:noshSocket ...

* ... has the extension keyword nosh-socket.
* ... has three source INI files, ${wibble}.socket, ${wibble}@.service, and
cyclog@.service
* ... configures for a rôle by:
1. install_file_copy()s all of ${wibble}.socket, ${wibble}@.service, and
cyclog@.service to /var/local/sv/
2. run_command()s system-control convert-systemd-units --local-bundle
--no-systemd-quirks --bundle-root /var/local/sv/ --
/var/local/sv/${wibble}.socket
3. run_command()s system-control convert-systemd-units --local-bundle
--no-systemd-quirks --bundle-root /var/local/sv/ --
/var/local/sv/cyclog@${wibble}.service 
4. symbolically links /var/local/sv/${wibble}/log to ../cyclog@${wibble}
5. run_command()s system-control enable -- cyclog@${wibble}.service
 ${wibble}.socket
6. run_command()s system-control start --verbose -- cyclog@${wibble}.service
 ${wibble}.socket
* ... deconfigures for a rôle by:
1. run_command()s system-control disable -- cyclog@${wibble}.service
 ${wibble}.socket
2. run_command()s system-control stop --verbose -- cyclog@${wibble}.service
 ${wibble}.socket
3. run_command()s system-control unload-when-stopped -- cyclog@${wibble}.service
 ${wibble}.socket
4. remove_file()s all of ${wibble}.socket, ${wibble}@.service, and
cyclog@.service from /var/local/sv/
5. removes the whole tree at /var/local/sv/${wibble}/ and at
/var/local/sv/cyclog@${wibble}/

I've not complicated the aforegiven by including all of the ${tuttle:id}s and
where they would be inserted into the file and directory names (just before
${wibble}, usually), on the presumption that you know all about that.

Then the INI files that you write for (say, HTTP being already taken in your
examples) nosh-socket gopherd would look like:

; gopherd@.service
[Unit]
Description=GOPHER service over IP4/IP6 using djbwares' gopherd
Description=http://jdebp.eu./Softwares/djbwares/

[Service]
EnvironmentDirectory=env
EnvironmentUser=%p-d
LimitNOFILE=20
LimitDATA=500
ExecStart=${localhost:+setenv ${PROTO:-TCP}LOCALHOST "${localhost}"} %p
${root:-/home/publicfile/public}

[Install]
WantedBy=server.target

; gopherd.socket
[Unit]
Description=GOPHER socket capable of single-stack IPV6 and IPV6-mapped IPV4

[Socket]
Backlog=2
ListenStream=gopher
Accept=true
MaxConnections=16
UCSPIRules=false
LogUCSPIRules=yes
NoDelay=false
BindIPv6Only=both

Setting up cyclog@.service, so that the generated /var/local/sv/cyclog@${wibble}
runs cyclog as user ${wibble}-l logging to /var/log/${wibble}, is an exercise in
more of the same that you only need to write once:

[Unit]
Description=Standard format %p logging service for %I
Before=%I

[Service]
WorkingDirectory=/var/log/
User=%i-l
ExecStart=%p %I/

[Install]
WantedBy=workstation.target

nosh version 1.33

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.33 .

* http://jdebp.eu./Softwares/nosh/
*
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project
* http://jdebp.info./Softwares/nosh/

This has been held back because of work being done by someone else.  I don't
want to steal xyr thunder, so I'll leave the announcement of that work to xem.
 Suffice it to say that it will interest a new group of people.

There are several major improvements in 1.33 .

Packaging
-

In the version 1.29 announcement I said that the Debian packaging system was
going to be brought into line with the system used for FreeBSD/TrueOS and
OpenBSD.  This is now done.  Debian and the BSDs all now use a similar system
for generating each package manager's package maintenance instructions from an
abstract package description.

==
=== IMPORTANT UPGRADE NOTE FOR Debian: ===
==

An important consequence of the aforementioned is that the semantics of the
nosh-bundles package have changed. In earlier versions, the various nosh-run-*
packages were how one set services running, except for a small rump set of
services that were set up by the nosh-bundles package.

This is now no longer the case. The nosh-bundles package now presets and starts
no services at all. *All* running of services must be achieved with the
nosh-run-* packages or some other sets of scripts and presets.

To this end, there are now two new packages, nosh-run-debian-desktop-base and
nosh-run-debian-server-base. These parallel the
nosh-run-{freebsd,trueos}-{desktop,server}-base packages already available since
1.29 for FreeBSD/TrueOS. You must install, for a working fully-nosh-managed
system, exactly one of the nosh-run-debian-{desktop,server}-base packages.

If you are running nosh service management under systemd, you can of course run
as many or as few services under the nosh service manager as you care to switch
over from systemd. But if you are running a fully-nosh-managed system these
packages will arrange to run the various fundamentals that one pretty much
cannot do without, such as mounting/unmounting volumes, running
udev/eudev/vdev/mdev, binfmt loading, and initializing the PRNG.

Log service account names
-

The naming scheme used for the user accounts for dedicated log service users has
changed.  Installing the new nosh-bundles package should automatically rename
all existing log service accounts to use the new scheme.

The new naming scheme is slightly more compact, and copes better with services
that have things like underscores and plus characters (e.g. powerd++) in their
names.

As an ancillary to this, system-control now has an "escape" subcommand which can
be (and indeed is) used in scripts to perform the escaping transformations.

More packages
-

There are now four more -shims packages, for commands whose names conflict with
commands from other packages: nosh-kbd-shims, nosh-bsd-shims, nosh-core-shims,
and nosh-execline-shims.

nosh-kbd-shims, for example, contains a chvt shim that is an alias for the (also
new) console-multiplexor-control command; with it, and suitable privileges to
access the virtual terminal's input queue, one can switch between multiplexed
user-space virtual terminals in much the same way as the old chvt command does
with kernel virtual terminals.

The Z Shell command-line completion for the various commands in the toolset
(system-control, svcadm, shutdown, svstat, and so forth), which has been
available to the people building from source for a while, is now also available
as a binary package.

Configuration import


ldconfig on TrueOS is now properly handled.  In particular, the external
configuration import subsystem now correctly pulls in and converts all of the
ldconfig directories.  (TrueOS has a lot more things that require ldconfig
support than stock FreeBSD does.)

The configuration import subsystem also now handles instances of Percona server,
alongside MySQL and MariaDB.  Moreover, these are now handled by the same set of
service bundles, which always produce service bundles named mysql@*.  MySQL
version 5.7 or later is now assumed.

The configuration import subsystem now automatically generates OpenVPN service
bundles based upon the current OpenVPN configuration.

===
 CAVE: OpenVPN 
===

The upgrade process attempts to remove the old hardwired openvpn@server and
openvpn@client service bundles.  However, you might encounter remnants of these
service bundles lying around in /var/sv that you will find that you need to
clean up by hand.

GOPHER
--

To accompany the new gopherd server in djbwares 5, there is a gopher6d service
bundle that runs it, serving up the same static files area as http6d, https6d,
and ftp4d do.

The FreeBSD, OpenBSD, and Debian package re

djbwares version 5

[Jonathan de Boyne Pollard]

djbwares is now at version 5.

* http://jdebp.eu./Softwares/djbwares/
* http://jdebp.info./Softwares/djbwares/

This contains some long-overdue changes: ip6.int has been replaced by ip6.arpa
in tinydns-data and dnscache, and rblsmtpd no longer falls back to using an RBL
that has been defunct for many years.

It also contains some additions: some UCSPI-SSL capability, a new gopherd UCSPI
server to go alongside httpd and ftpd in publicfile, and most of the previously
missing manual pages (including a few for commands which had no manuals in the
original toolsets).

There are no longer any placeholder manual pages for the "man" command.  There
are still a few manual pages that are only present in roff form, though.

You can see gopherd in action:

* gopher://jdebp.info./1/Repository/ 

Early boot became slower

[Jonathan de Boyne Pollard]

Felix Miata:

At what point exactly within either of those videos does 80 by 25 
appear? All I saw anywhere appeared to be in the vicinity of 240 by 67.




I think that I have put my finger on the source of your perplexity.  
Remember where M. Oss said the following?


Mattia Oss:


This can be seen in the 3rd video.



There's a third video, and it appears in the third video. It's 
definitely 80*25 VGA text mode in that third video. And just as M. Oss 
said, the text in the third video scrolls fairly briskly and the 
characters are ...



Mattia Oss:


HUGE characters.

... as one would expect with 80 columns by 25 rows on a widescreen 
display of that size.


Now M. Oss and all of you get to play with the different ways that the 
VESA driver can do scrolling. (-:

nosh version 1.32

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.32 .

* http://jdebp.eu./Softwares/nosh/

* 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project


* http://jdebp.info./Softwares/nosh/

This release fixes two problems with Gentoo Linux (control group version 
detection and a problem with mounting API filesystems) that we hashed 
out on the Supervision mailing list.  It furthermore contains a change 
to the way that convert-systemd-units generates service bundles that 
fixes problems with control group setup when the service unit defines a 
"slice" for the service or when the service unit is a template. In 
furtherance of that there's a new create-control-group command.


Other things in this release include improvements to the (unpackaged) Z 
Shell command-line completions, which now display option completion 
menus properly; some improvements to the Terminals chapter in the Guide; 
fixes to various service bundles that were using shell reserved words 
and operators such as "for" and "&&" without explicitly invoking the 
shell; additions to userenv for setting DBus and XDG Runtime variables; 
and a fix that prevents "system-control reset" from looping indefinitely 
when run by an unprivileged user such as "messagebus" that lacks access 
to the control/status API.


The major improvement in this release, though, is to console-fb-realizer 
on TrueOS.


FreeBSD gives console-fb-realizer uhid device files to use for input 
devices, which speak the USB HID report protocol and which 
console-fb-realizer has been happy with for a long time.  TrueOS 
provides either ums/ukbd devices, which lack various features because 
they speak the old sysmouse and atkbd protocols, or ugen devices.  There 
are no uhid devices available. console-fb-realizer can now use the ugen 
devices.  Moreover, it will detach the ums/ukbd drivers from the ugen 
devices using the new detach-kernel-usb-driver command, so that there 
aren't two things both attempting to read HID reports.


console-fb-realizer also now correctly sets the keyboard LEDs on both 
FreeBSD and TrueOS.


There have been several minor adjustments to the kernel VT sharing parts 
of console-fb-realizer, preparatory to splitting the program up into 
separate parts for input and output devices, permitting things such as 
multiple keyboards each with its own keyboard map and numlock semantics, 
in a future release.

Early boot became slower

[Jonathan de Boyne Pollard]

Mattia Oss:


This can be seen in the 3rd video.


Lisi Reisz:


By you. Not by me - nor apparently by Felix.



It's really simple.  It's the same size monitor.  The "normal" 
characters are high resolution 24-bit colour graphics mode with 8*16 
pixel glyphs, giving 240 columns by 67 rows.  The "huge" characters are 
VGA text mode at 80 columns by 25 rows, giving glyphs that are in effect 
more than 24*32 pixels.


As for why graphics mode has slowed down going from simple-framebuffer 
to vesafb, consider this and its implications:



vesafb: scrolling: redraw

nosh with Debian's sysstat package

[Jonathan de Boyne Pollard]

Someone:

I haven't installed much else yet on the system but I tried the 
sysstat package which gives me the following error:



preset: ERROR: sysstat: No such file or directory


I haven't yet investigated this problem. Sysstat seems to be part of 
the Debconf enable/disable system, I'm not quite sure how that 
interacts with nosh.




This is a good example for general consumption.

The maintenance script for the package is trying to enable the "sysstat" 
service using the "update-rc.d" command.  You've installed the shim for 
this command from the nosh-debian-shims package, so the maintenance 
script is actually ending up trying to preset the "sysstat" service 
bundle using "system-control preset".  You don't have a "sysstat" 
service bundle.  Yet.


Ironically, if the systemd support in Debian's "sysstat" were as good as 
the author's own, you could just make one.  The origin package comes 
with a systemd service unit, built by passing this through a macro 
processor to turn things like @SA_LIB_DIR@ into "/usr/lib/sysstat":


* https://github.com/sysstat/sysstat/blob/master/sysstat.service.in

Debian, however, only builds and packages up a Debian-supplied van 
Smoorenburg rc file.  It doesn't actually package up the systemd support 
that comes from the author.  It does provide the /usr/lib/sysstat/sa1 
script that is referenced by the systemd service unit, however.  So you 
could take the sysstat.service.in, manually make a sysstat.service out 
of it, and pass that through convert-systemd-units to make a service 
bundle that would invoke /usr/lib/sysstat/sa1 .


However, we are heading into systemd House of Horror territory here, as 
Debian also provides a "Debianized" version of the sa1 script as 
/usr/lib/sysstat/debian-sa1 that does the stuff that Debian's van 
Smoorenburg rc script does.  So using what's in the box we would have 
sysstat.service which sets up settings the systemd way, running the 
debian-sa1 script that sets up things the Debian way (reading 
/etc/defaults/sysstat), running the sa1 script that sets things up the 
RedHat/SuSE way (/etc/sysconfig/sysstat).  It's a mess of nested shell 
scripts and overlapping configuration mechanisms.  And that's 
overlooking the surprise secret second service disable mechanism.


The systemd people don't like surprise secret second service disable 
mechanisms, and the modern Debian practice is to not have them.  The 
Debian sysstat package has more than one thing to improve.  Moreover 
there's no real need for all of these configuration mechanisms, 
especially since the underlying command has only two knobs to twiddle in 
the first place.  So start with a more ideal-world version of what 
sysstat should have for systemd: a simple service unit that has 1 
configuration mechanism, and cuts out all of the daft middle-men layers 
of shell scripting entirely.


1. Take this service unit instead.  Call it sysstat.service .
2. Use convert-systemd-units to make a service bundle from it. chown 
everything to root if you didn't do this as root.

3. Place that in /var/local/sv/sysstat .
4. install -d -m 0755 /var/local/sv/sysstat/service/env
5. system-control set-service-env sysstat OPTIONS -D

See what happens when you install the package then.

  [Unit]
  Description=Insert a dummy record in sysstat's current daily data 
file to indicate that the counters have restarted from 0.


  [Service]
  # The service is "ready" after it has run to completion.
  Type=oneshot
  # This enables controlling service options with rcctl set and rcctl get .
  EnvironmentDirectory=env
  # Two - characters, note.  Also, this is specifically targetting 
being converted into a nosh service bundle.

  ExecStart=/usr/lib/sysstat/sadc -F -L ${OPTIONS} "${DIR:--}"

  [Install]
  WantedBy=workstation.target

What in /var/logs shows system reboot?

[Jonathan de Boyne Pollard]

Joe:


Using strings /var/log/journal/*/* | grep debian-kernel [...]



Or one could just use journalctl .

nosh version 1.31

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.31 .

* http://jdebp.eu./Softwares/nosh/

* 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project


* http://jdebp.info./Softwares/nosh/

This release fixes a problem with emergency mode that was introduced by 
accident in 1.29 .  The emergency-login@console service was not properly 
enabled by package installation.  Now it once again is.


There are a number of bug fixes in this release, such as rare corner 
cases in how convert-systemd-units generates arguments to pass to sh, 
what port the nginx server part of Appcafe binds to when not the 
default, the use of setuidgid-fromenv to set more than 1 supplementary 
group ID, and making the Makefile in tinydns@* services work with both 
BSD and GNU make.  Various service bundles that perform 
clean-up-directories actions at bootstrap have been made more difficult 
to accidentally re-trigger after bootstrap.


There is also a fair amount of new features:

* The automatically-generated data for tinydns@* services now 
encompasses all of the reverse lookup domain names for private/local IP 
addresses, so none of the DNS traffic involving such lookups will leak 
out of your machine/organization to the rest of Internet.


* The userenv command has gained the ability to (optionally) set a whole 
lot more environment variables from the capabilities in /etc/login.conf 
and ~/.login_conf .  It now can be used as the 
setup-the-user-environment part of a command chain that is designed to 
perform the setup of an interactive login session. This is particularly 
useful for fixing PCDM, the display manager in TrueOS.


* The pipe command can now arrange to clean up the child process in one 
of two ways.  This is made use of in the dnscache service bundles, and 
dnscache services no longer contain the perpetual zombie process that 
they had in version 1.30 .


* Presets now support wildmat-style character set wildcards. e.g. one 
can now write "ttylogin@vc[0-9]-tty" as a service name pattern.


* If you have been using the --verbose option to the start/stop/reset 
subcommands of system-control, you'll notice that it now colourizes its 
output.  Its output has also been adjusted to more clearly indicate 
blocked services and what they are blocked by.


The big item is that there is now a complete set of simple control 
groups manipulation commands, the pre-supplied service bundles all make 
use of it, and all service bundles created by convert-systemd-units make 
use of it.  (All of this is a no-op on FreeBSD/TrueOS and OpenBSD, of 
course.)


If you've read the Linux doco, you'll know that control groups do not 
require any sort of centralized gatekeeper process, and are a 
decentralized system that can be driven with just the echo command.  In 
practice, using echo is non-trivial.  The move-to-control-group, 
delegate-control-group-to, and set-control-group-knob commands take the 
hassle out of working out exactly what to echo where.  They do all of 
the hard work of determining what the directory name of the current 
control group under /sys/fs/cgroup is, and present a simple system 
allowing one to create and navigate to another control group, delegate 
control over the current control group (and its subgroups) to an 
unprivileged user, and set control group knobs.


The set-control-group-knob utility further illustrates the convenience 
functionality over and above a simple echo command. It can calculate a 
knob setting as a percentage of another number, handle SI and IEEE/IEC 
multiplier suffixes, and translate the device file names that are 
(comparatively) convenient for humans into the literal major and minor 
device numbers that the Linux control groups API actually operates in 
terms of.


There are new chapters in the Guide covering the automatic import of 
FreeBSD 9 and PC-BSD Warden jails, how jailing services on 
FreeBSD/TrueOS works, and limiting services.  The limiting services 
chapter covers both the original Unix resource limits system and Linux 
control groups.

nosh version 1.30

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.30 .

* http://jdebp.eu./Softwares/nosh/
* 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project

* http://jdebp.info./Softwares/nosh/

service bundles
---

As usual, there are more service bundles, including for the UWSGI 
"Emperor" and the new services in FreeBSD/TrueOS 11 such as ypldap. 
There are now services to run Sendmail in the same manner as the 
services that run exim.  Note that this is slightly different to the old 
FreeBSD division of labour.  There are individually controllable 
services for SMTP Submission, SMTP Relay, the Submission queue runner, 
and the Relay queue runner.


doco


The Guide has been extended with several new chapters, including a 
gazetteer of interesting directories, a chapter on log file 
post-processing, a chapter on logging security, a chapter on per-user 
service management, and some notes for individual services.  The 
commands list has moved from the blurb into the Guide, too, as it seems 
like something that an administrator might find handy to have available 
when there's no Internet connection.


* http://jdebp.eu./Softwares/nosh/guide.html

service management
--

There's now a hardlimit chain-loading command, analogous to softlimit.  
The convert-systemd-services utility now makes use of this and permits 
setting separate hard and soft limits, or only one or the other, with 
settings like LimitOFILE=32:128 and LimitNPROC=:infinity .


There's now a local-reaper chain-loading command, that can turn "local 
reaper" status for the current process on or off.  Have a care when 
using this, per the note on the manual page.  There is a 
LocalReaper=true extension to systemd service units for this.


netlink-datagram-socket-listen is now available on the BSDs for script 
compatibility.  It always aborts with an address family error.


There's a new hangup subcommand of system-control, equivalent to the 
existing -H option to svc .


enhancements to system-control stop/start/reset and single-shot services


This is the first big item for 1.30 :

The start and stop subcommands of system-control now operate more 
quickly.  Instead of polling once per second, they monitor the 
supervise/status files of each service that is in the process of being 
started and stopped, with kevent().


In addition, system-control now supports the notion of services that 
become ready when their main process has exited, marked with a new flag 
file in the service directory.  convert-systemd-units has been modified 
to convert "oneshot" services to this, instead of to services that put 
all of the run code into the start program.  Thus "oneshot" services 
that are running their actual main programs are reported as "running" by 
svstat, rather than as "starting".


This takes advantage of the extended status information that 
service-manager has been writing to the status file since version 1.28.  
The sharp-eyed may have noticed that in version 1.28 the output of 
"svstat"/"system-control status" gained information about the exit 
statuses of the start, run, restart, and stop programs. This is what 
system-control now uses to detect whether ready-after-run services ran 
before they stopped.  (Detection of ready-after-run services that are 
running with no processes, because they are "remain" services, can be 
and is done with just the daemontools-encore-compatible status information.)


Old-style "oneshot"s will continue to work as before, as of course they 
become ready as soon as the run process is spawned, which is after they 
have run their programs as part of start.


The benefit of this new style, apart from reporting a running service as 
actually "running", which should help with nagios monitoring and the 
like, is that "oneshot" services converted from systemd no longer have 
to be marked as RemainAfterExit=true in order to avoid a dummy "pause" 
process hanging around.  This is the case for old-style "oneshot" 
services.  They have to run something in run, after all, and that 
something has to keep running in order for the service to be considered 
ready and services ordered after it to be unblocked.  A ready-after-run 
service, however, unblocks ordered-after services if it has reached the 
stopped state via a run, thus puts its programs in run, thus doesn't 
have to have a dummy pause process, and can be RemainAfterExit=false 
without adding to the process list.


log file management
---

export-to-rsyslog had a bug that caused it to skip old log files (the 
@.s ones) in catch-up mode.  This has been 
corrected.  There is now a follow-log-directories command that can 
substitute for tail -F .  It knows the actual structure of log 
directories, operates using one or more cursors like export-to-rsyslog 
does, and copes correctly with cyclog/multilog log rotation (which GN

systemd-journald fails to start due to corrupted /etc/machine-id (was: Re: systemd-journald fails)

[Jonathan de Boyne Pollard]

Rainer Dorsch:


But to my surprise even on a fresh install of the jessie image 
/etc/machine-id is already broken:



root@scw-790923:~# cat /etc/machine-id

9d1b906dd5ea40359e2071d29c12aabe

71f

root@scw-790923:~#

But it seems the systemd version in jessie seems to be more tolerant 
against broken machine-id fails (?).


It is.  Lennart Poettering introduced this intolerance on 2016-07-21.  
Before then, /etc/machine-id could contain other stuff after the first 
line, and systemd would ignore it because it only ever read and wrote 
the 32-character ID and the newline of the first line of the file.  
Lennart Poettering changed an I/O function call from an exact length 
read of 33 characters to a variable length read of up to 38 characters 
followed by a check that the number of characters read is only ever 33, 
and the intolerance is as you see now.


So your machine IDs have possibly been like this for a long time.

Your next stops are https://github.com/systemd/systemd/issues/4025 and 
https://github.com/scaleway/image-tools/issues/181 .

Re: systemd-journald fails

[Jonathan de Boyne Pollard]

Rainer Dorsch:

[ 20.704584] systemd[1]: Initializing machine ID from D-Bus machine ID.

[ 20.916182] systemd-journald[2136]: Failed to open runtime journal: 
Invalid argument




You need to look at at least two files, /var/lib/dbus/machine-id and 
/etc/machine-id .  They should contain only a 128-bit hexadecimal number 
plus a newline, and this number must match the number used in the 
directory names below /run/log/journal/ and /var/log/journal/ .

Re: djbwares version 4

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:

In celebration of the forthcoming leap second, djbwares is now at 
version 4.


* http://jdebp.eu./Softwares/djbwares/
* http://jdebp.info./Softwares/djbwares/


Jean Louis:


http://jdebp.info./Softwares/djbwares

is not working: "access denied" and I instinctively tried that one 
first, as to avoid .eu (even it makes no sense).




You should have just tried the URL that I gave to you, without your 
changing it to something different.


Ironically, Bernstein publicfile is part of the package at hand, and 
this is the documented behaviour of publicfile, in its original 
Bernstein manual:


> A request for http://v/f refers to the file named ./v/f inside 
the root directory hierarchy, if f does not end with a slash.


> httpd will refuse to read a file if the file [...] is anything other 
than a regular file: a directory, socket, device, etc.


publicfile isn't going to let you read the WWW server's directories 
directly with URL tricks.  You attempt that in vain.  (-:  For *not* 
trying to trick the WWW server, and simply reading the blurb and the 
download instructions, just use the actual URL that I gave.

Re: systemd-journald fails

[Jonathan de Boyne Pollard]

Rainer Dorsch:

> I think this then results in errors during an apt-get upgrade:

It does indeed.  It is systemd-journald that resides at the server end 
of /dev/log on a systemd operating system.  Quite a lot of other stuff 
will break for you if you don't have a running systemd-journald, because 
there are quite a lot of things plumbed into systemd-journald, not least 
the standard outputs of many of the services on your system.


Restarting systemd-journald historically has not worked *a lot* in 
systemd.  Bugs about it abound.  Things just don't get hooked back up 
correctly, and services are surprised and confused by EPIPE errors and 
SIGPIPE signals when simply writing to their standard output or error.


* https://bugzilla.redhat.com/show_bug.cgi?id=1378929
* https://bugs.freedesktop.org/show_bug.cgi?id=84923
* https://github.com/chef-cookbooks/chef-client/issues/359
* https://bugs.freedesktop.org/show_bug.cgi?id=56043
... and so on.

You need systemd-journald running.  Your best course of action is to see 
whether it comes up properly at bootstrap, in normal, rescue, or 
emergency mode.  If it does not, then *why* is pretty much the first 
problem that you need to solve.  Note that it is correct for the service 
unit to be "static" rather than "enabled".  The unit that needs to be 
"enabled" is systemd-journald.socket, which is what fires up 
systemd-journald.service.


Of course, if a service does not come up, the first port of call is the 
log from the service manager to see what errors are recorded, the 
infamous "So what do 'journalctl -u systemd-journald -e -b' and 
'systemctl status systemd-journald' say?".  But in the systemd world 
that log is also managed by systemd-journald.  Chicken.  Egg.


(This is why designs in the daemontools family world have more than one 
log daemon.  Laurent Bercot describes things in terms of a "logging 
chain".  If mysqld doesn't start, then one consults the logs maintained 
by its (individual) log service.  If the mysqld log service itself 
didn't start, then one consults the logs maintained by the service 
manager's own (distinct) log service.)


> Dec 4 09:44:48 scw-1fe3cf systemd[1]: 
[/lib/systemd/system/systemd-journald.service:25] Unknown lvalue 
'FileDescriptorStoreMax' in section 'Service'


Oh look. The version of systemd that you have doesn't like the settings 
in the systemd-supplied service units that you have. Have you checked 
that everything is at the same version?


> Dec 4 09:44:38 scw-1fe3cf systemd[1]: 
[/lib/systemd/system/emergency.service:19] Not an absolute path, 
ignoring: -/root


> Dec 4 09:44:38 scw-1fe3cf systemd[1]: 
[/lib/systemd/system/rescue.service:18] Not an absolute path, ignoring: 
-/root


The version of systemd that you have doesn't like some other settings, 
too.  Rescue and emergency modes are going to be interesting for you, I 
suspect.

Document and LBC (Was: Debian *not very good)

[Jonathan de Boyne Pollard]

Greg Wooledge:

Neither of those links talks about jessie's specific default script that waits 
for network interfaces to start.


They do, however, explain what LSB has to do with things, which was what you 
wondered about.

Greg Wooledge:

Neither do they mention this "van Smoorenburg".


Miguel van Smoorenburg.  He originally wrote the rc system that ran that 
script.  Other rc systems include the one written for NetBSD by Luke Mewburn.

djbwares version 4

[Jonathan de Boyne Pollard]

In celebration of the forthcoming leap second, djbwares is now at version 4.

* http://jdebp.eu./Softwares/djbwares/
* http://jdebp.info./Softwares/djbwares/

I've added in the rest of M. Bernstein's public domain libtai library, 
parts of which were already included by some of the tools.  This has 
added the easter, nowutc, and yearcal commands, which are packaged up 
alongside libtai.a, the libtai C language headers, and the libtai manual 
pages in a new libtai package.


More importantly, it has added the leapsecs command, and the 
/usr/local/etc/leapsecs.dat file is now generated from leapsecs.txt 
rather than included as a binary in the source as it was before.  The 
sharp-eyed will also note that support for /usr/local/etc/leapsecs.dat 
(as an alternative to /etc/leapsecs.dat for systems that like 
non-operating system files in /usr/local/etc) has also been added.  The 
leapsecs.txt is the Bernstein 2015-06-30 version (which is still the 
latest published by M. Bernstein) patched with the forthcoming leap second.


The libtai package does not include /usr/local/etc/leapsecs.dat .  
Rather, that is packaged in a separate leapsecs package, to allow 
updated versions to be substituted with ease when they come along, as 
well as to permit installing only that without the rest of libtai.

Jessie upgrade without systemd [was: Debian *not very good]

[Jonathan de Boyne Pollard]

Joe:

A fair number of wheezy systems will be servers, upgraded many times. 
Mine started out as sarge. What are the odds of such a system making 
the change to systemd without problems?




It depends.  But my own experience is that *if they were already using 
systemd* on Debian 7, it was a certainty that Debian bug #774153 will 
rear its ugly head in an upgrade to Debian 8.  I personally hit it with 
every single such system that I upgraded. I hit it on test systems 
first, of course.  So I had to put retaining shell access during the 
upgrade, to wait for the indeterminate point somewhere in the midst of 
about seven hundred package upgrades (alas, not at the same point on 
every machine) that one needs to go in and hand-run "daemon-reexec", 
into the upgrade procedure.

Document and LBC (Was: Debian *not very good)

[Jonathan de Boyne Pollard]

Anonymous:

The error message:"A start job is running for LSB: Raise 
network interface (xx sec/no limit)". Where xx is a count up in 
seconds that never ends.




Greg Wooledge:

"LSB" stands for Linux Standard Base [...] I don't know what LSB has 
to do with Debian's boot process waiting for the network interfaces to 
be configured before proceeding.




The systemd doco doesn't cover it.  Here you go:

* http://unix.stackexchange.com/a/233581/5132

* http://unix.stackexchange.com/a/326354/5132

So xe has an old van Smoorenburg rc script whose description is "Raise 
network interface", and that old rc script not completing its work is 
the problem.

Re: nosh version 1.29

[Jonathan de Boyne Pollard]

Bloody Thunderbird!  Here's that again, I hope without the surprise 
reformatting after pressing "send" this time:


The nosh package is now up to version 1.29.

* http://jdebp.eu./Softwares/nosh/
* 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project

* http://jdebp.info./Softwares/nosh/

There's been a lot going on since version 1.28 .

2016 leap second


The TAI to UTC conversions know about the forthcoming leap second.

service bundles
---

As usual, there are several new service bundles, from powerd++ through 
zfsd to fwknopd.  The new fs-servers target allows one to order the 
initialization of NFS servers before loop-to-self NFS mounts.  The new 
multi-user-pre target is another ordering target that allows services 
such as the motd file updater to be ordered before TTY login services.  
The instantiated kdm@tty7 and kdm@ttyv6 services have been replaced with 
a single kdm service, with a view to dealing with display managers 
better in the future.  I have some plans in this area.


The Samba service names have been fixed.  Debian calls them nmb, smb, 
and winbind; but the Samba doco and most places on the WWW call them 
nmbd, smbd, and winbindd.  The latter names are used in the service 
bundles package, with aliases pointing to them from the Debian names.


doco


The doco has been improved and kept up-to-date in various places, 
including correct descriptions of set-service-env and print-service-env 
after one confused user got in touch.  PC-BSD is now named as TrueOS 
where the reference is not historical.


code review
---

As a result of some code review that was offered, std::auto_ptr is now 
gone and a rare memory corruption bug in safe_execvp() has been fixed.  
Building from scratch when one doesn't have a prior daemontools or 
freedt toolset installed also no longer hits a bug.


configuration import improvements
-

In an effort to clear those last few remaining items on the nosh 
roadmap, a whole load of configuration import (pppd, sppp, rfcomm_ppp, 
dhclient, wpa_supplicant, natd, and hostapd) has been consolidated under 
the umbrella of static-networking.  I plan to expand this further in 
1.31, given how much is already in 1.30.


Linux kernel VTs


Management of Linux kernel virtual terminals has some improvements, 
including setting UTF-8 canonical mode editing and keyboard composition 
modes, and emitting the control sequences that set up the screen saver.


tai64nlocal changes
---

tai64nlocal has adopted a minor but important change from the BSD and 
GNU C libraries: before reading the start of a line it flushes its 
output.  This came from trying to use it as a co-process in GNU awk.  To 
prevent deadlocks, GNU awk co-processes need to be in what is 
effectively line buffered output mode even though their standard inputs 
and outputs are not terminal devices.  This is now the case for 
tai64nlocal and it can be used to convert TAI64N timestamps as a GNU awk 
co-process.


FreeBSD and TrueOS packaging


The largest change, however, is in the FreeBSD/TrueOS and OpenBSD packaging.

This is a change that is going to happen in the Debian packaging in a 
later version.  It's partly to simplify the package maintenance, and 
partly a step towards having OpenBSD packages that work.  A single 
package description is fed to both the new pkg tool that exists on 
FreeBSD/TrueOS and the old pkg tool that exists on OpenBSD.  It's not 
perfect, as there are things that are easy with the new pkg tool that 
are hard with the old one; and the OpenBSD packages are still not fully 
functional.  But things are better than they were.  The OpenBSD service 
bundles package now almost properly sets up per-service user accounts 
and log directories, for example.


===
===  IMPORTANT UPGRADE NOTE FOR FreeBSD/TrueOS: ===
===

An important consequence of the aforementioned is that the semantics of 
the nosh-bundles package have changed.  In earlier versions, the various 
nosh-run-* packages were how one set services running, except for a 
small rump set of services that were set up by the nosh-bundles 
package.  This is now no longer the case.  The nosh-bundles package now 
presets and starts no services at all. *All* running of services must be 
achieved with the nosh-run-* packages or some other sets of scripts and 
presets.


To this end, there are now two new packages, 
nosh-run-freebsd-desktop-base and nosh-run-freebsd-server-base. These 
parallel the already existing nosh-run-trueos-desktop-base and 
nosh-run-trueos-server-base packages; except that they do not start any 
of the services that exist in TrueOS but do not exist in FreeBSD, such 
as the various pc-* services.


You must install,

nosh version 1.29

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.29. * 
http://jdebp.eu./Softwares/nosh/ * 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project 
* http://jdebp.info./Softwares/nosh/ There's been a lot going on since 
version 1.28 . 2016 leap second  The TAI to UTC 
conversions know about the forthcoming leap second. service bundles 
--- As usual, there are several new service bundles, from 
powerd++ through zfsd to fwknopd. The new fs-servers target allows one 
to order the initialization of NFS servers before loop-to-self NFS 
mounts. The new multi-user-pre target is another ordering target that 
allows services such as the motd file updater to be ordered before TTY 
login services. The instantiated kdm@tty7 and kdm@ttyv6 services have 
been replaced with a single kdm service, with a view to dealing with 
display managers better in the future. I have some plans in this area. 
The Samba service names have been fixed. Debian calls them nmb, smb, and 
winbind; but the Samba doco and most places on the WWW call them nmbd, 
smbd, and winbindd. The latter names are used in the service bundles 
package, with aliases pointing to them from the Debian names. doco  
The doco has been improved and kept up-to-date in various places, 
including correct descriptions of set-service-env and print-service-env 
after one confused user got in touch. PC-BSD is now named as TrueOS 
where the reference is not historical. code review --- As a 
result of some code review that was offered, std::auto_ptr is now gone 
and a rare memory corruption bug in safe_execvp() has been fixed. 
Building from scratch when one doesn't have a prior daemontools or 
freedt toolset installed also no longer hits a bug. configuration import 
improvements - In an effort to clear 
those last few remaining items on the nosh roadmap, a whole load of 
configuration import (pppd, sppp, rfcomm_ppp, dhclient, wpa_supplicant, 
natd, and hostapd) has been consolidated under the umbrella of 
static-networking. I plan to expand this further in 1.31, given how much 
is already in 1.30. Linux kernel VTs  Management of 
Linux kernel virtual terminals has some improvements, including setting 
UTF-8 canonical mode editing and keyboard composition modes, and 
emitting the control sequences that set up the screen saver. tai64nlocal 
changes --- tai64nlocal has adopted a minor but 
important change from the BSD and GNU C libraries: before reading the 
start of a line it flushes its output. This came from trying to use it 
as a co-process in GNU awk. To prevent deadlocks, GNU awk co-processes 
need to be in what is effectively line buffered output mode even though 
their standard inputs and outputs are not terminal devices. This is now 
the case for tai64nlocal and it can be used to convert TAI64N timestamps 
as a GNU awk co-process. FreeBSD and TrueOS packaging 
 The largest change, however, is in the 
FreeBSD/TrueOS and OpenBSD packaging. This is a change that is going to 
happen in the Debian packaging in a later version. It's partly to 
simplify the package maintenance, and partly a step towards having 
OpenBSD packages that work. A single package description is fed to both 
the new pkg tool that exists on FreeBSD/TrueOS and the old pkg tool that 
exists on OpenBSD. It's not perfect, as there are things that are easy 
with the new pkg tool that are hard with the old one; and the OpenBSD 
packages are still not fully functional. But things are better than they 
were. The OpenBSD service bundles package now almost properly sets up 
per-service user accounts and log directories, for example. 
=== 
=== IMPORTANT UPGRADE NOTE FOR FreeBSD/TrueOS: === 
=== 
An important consequence of the aforementioned is that the semantics of 
the nosh-bundles package have changed. In earlier versions, the various 
nosh-run-* packages were how one set services running, except for a 
small rump set of services that were set up by the nosh-bundles package. 
This is now no longer the case. The nosh-bundles package now presets and 
starts no services at all. *All* running of services must be achieved 
with the nosh-run-* packages or some other sets of scripts and presets. 
To this end, there are now two new packages, 
nosh-run-freebsd-desktop-base and nosh-run-freebsd-server-base. These 
parallel the already existing nosh-run-trueos-desktop-base and 
nosh-run-trueos-server-base packages; except that they do not start any 
of the services that exist in TrueOS but do not exist in FreeBSD, such 
as the various pc-* services. You must install, for a working 
fully-nosh-managed system, exactly one of these four packages. If you 
are running nosh service management under Mewburn rc, you can of cou

debian version ID

[Jonathan de Boyne Pollard]

Felix Miata:

Will someone please explain (or point to, since it's not in release 
notes), why:
1: /etc/os-release (in Jessie at least) does not include the point 
release version as represented by /etc/debian_version


Andrew M.A. Cater:

/etc/os-release just contains major version - the absolute need for 
minor version is small.


Jonathan de Boyne Pollard:

You are going to have to explain that to its manual page, which gives 
VERSION_ID=11.04 as an example of what can be in the file.


Pascal Hambourg:


This is obviously not a Debian version. Rather looks like Ubuntu.


That is irrelevant.  M. Miata asked for a reason.  M. Cater responded.  
Either M. Cater is responding to explain why or xe is not explainining 
but merely repeating what M. Miata already knows and wants to know the 
reason for.  As an explanation why, it is clearly wrong, from simply 
reading the user manual.  What the version number in the manual might be 
is simply irrelevant.

Re: nosh version 1.28

[Jonathan de Boyne Pollard]

I don't know why you asked about FreeBSD rc.d just on the Debian mailing 
list; but I'm going to deal in both of those and others besides, here, 
and things that apply across both, so I've re-included the FreeBSD 
mailing list.  (-:


2016-08-14 15:10, Julian Elischer:

I don't know if I just missed it, or it isn't there but  I have a 
question..


You give examples of importing systemd service files.  What about 
importing rc.d files with all their ability to run arbitrary shell 
commands.


And once you have the services defined, what is the logical equivalent 
of rc.conf, which can supply parameters for each service and turn them 
on and off?  can you import from rc.conf?



You did miss it.  (-:

What you missed has grown to be a significant subsystem. It was actually 
mentioned a couple of times in the 1.28 announcement. It's the external 
configuration import subsystem.  You can read about it in the nosh Guide:


xdg-open /usr/local/share/doc/nosh/external-formats.html

As you can see, there's a whole section on importing from rc.conf into 
native service management mechanisms.  ("rc.conf" covers several 
sources, note, including a FreeNAS configuration database and 
/etc/defaults/rc.conf .)


The native service mangement mechanisms are the "enable" and "disable" 
subcommands to the system-control command, and using the envdir command 
in the normal daemontools-family style way.  The enable/disable 
mechanism in "rc.conf" is treated as if it were a preset (in systemd 
nomenclature).  You tell service management to "preset" a service, and 
it will look at /etc/rc.conf and /etc/rc.conf.local (as well as some 
other preset mechanisms) to determine what to set the native 
enable/disable state to.  The user manual page for the preset subcommand 
(of system-control) explains what the preset mechanisms are in detail.


You can set up environment directories how and where you like, but 
there's a convention that is shared by the "convert-systemd-units" tool, 
the "rcctl" shim, and the external configuration import subsystem as a 
whole. This convention is an environment directory named "env" that is 
in the service directory.  The "rcctl" shim gets and sets variables 
there; and the import subsystem places converted "rc.conf", /etc/fstab, 
/etc/ttys, /etc/my.cnf, and other stuff there.


One example of this in action, out of many in the import subsystem, is 
jails that have been set up the version 9 way in "rc.conf".  Those are 
turned into service bundles, with "env" environment directories that 
contain environment settings such as "hostname", "mount_devfs", and 
"interface".  The "run" script for the jail service very simply turns 
the environment variables into arguments to the "jail" comand.  In a 
system with an original OpenBSD "rcctl" command, one would expect to be 
able to set (version 9) jail control variables by manipulating 
/etc/rc.conf with commands like "rcctl set wibble hostname wobble".  The 
"rcctl" shim and this shared convention mean that one need not stray 
that far from this if "rcctl" is one's habit: "rcctl set v9-jail@wibble 
hostname wobble" does the "native" thing of setting the "hostname" 
variable in the (conventional) environment variable directory for the 
"v9-jail@wibble" service.


Bonus feature for those with other habits: With nosh service management 
in place, one can actually import from /etc/rc.conf settings *on Debian* 
(as long as one sets up a FreeBSD/PC-BSD-style /etc/defaults/rc.conf 
pointing to it with rc_conf_files).  One can use /etc/ttys, too.


As for importing scripts that run "arbitrary shell commands", there are 
several points.


First, you may not need to.  Note that most of what you get out of the 
box in /etc/rc.d/ and /usr/local/etc/rc.d/ on FreeBSD and PC-BSD has 
already been converted.  Remember that project that I had to convert 157 
services?  Take a look at the nosh roadmap page.  It's almost done.


Second, you may not need to.  Take a look at what actually comes in the 
nosh-bundles package nowadays.  Discounting the 'cyclog@' service 
bundles there are just over 540 service bundles in there, from samba to 
ntp, from saned to ossec@agentd.  (Including the 'cyclog@' service 
bundles, it is over a thousand service bundles.)  The Debian world 
doesn't get left out, either. Although it's a lot more difficult than in 
the BSD worlds to come up with a list of "core" Debian services, a lot 
of the basics of Debian are also covered by this, from kernel-vt-setfont 
through irqbalance to update-binfmts.  And those more-than-540 service 
bundles cover lots of "non-core" stuff, from (as aforementioned) 
OSSEC-HIDS, Salt, and RabbitMQ to publicfile httpd over IPV6.


Third, you may not need to.  This was mentioned in the 1.28 
announcement, in fact.  The external configuration import subsystem 
makes *further* service bundles, beyond the pre-made ones that come in a 
binary package.  It creates service bundles to run (optional) per-user 
service management,

Are Debian online manpages down?

[Jonathan de Boyne Pollard]

Felix Miata:

Only with that one particular URL.


... which is officially recognized.

* https://debian.org/News/weekly/2013/19/index.en.html#manpages

debian version ID

[Jonathan de Boyne Pollard]

Andrew M.A. Cater:

/etc/os-release just contains major version


You are going to have to explain that to its manual page, which gives 
VERSION_ID=11.04 as an example of what can be in the file.


You're going to have to explain it to the Ubuntu people, as well; 
because they follow what the manual says.  (-:


In reality, /etc/os-release can contain both major and minor versions, 
and does on Ubuntu, OpenSUSE, and so forth.  Why it does not on Debian 
is not something that is imposed by the file format.

Re: invoke-rc.d

[Jonathan de Boyne Pollard]

André Majorel:
Do you think the following would work on any Debian system, regardless 
of its current run level and choice of init system ?


1. run invoke-rc.d daemon-package stop
2. update config file
3. run invoke-rc.d daemon-package start 


Don't use invoke-rc.d yourself.  The *old pre-systemd* Debian Policy 
Manual vaguely and indirectly warns against it; my proposed revised 
systemd-aware Debian Policy Manual explicitly warns against it, based 
upon discussions during the Debian systemd Hoo-Hah; the manual page for 
my invoke-rc.d shim warns against it; even the Debian/Ubuntu manual page 
indirectly explains what it is not for. It is for a very particular 
need.  It is not for general service management tasks by a system 
administrator.  Use the "service" command.


* https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
* https://jdebp.eu./Proposals/DebianPolicy/ch-opersys.html#s-sysvrc
* 
https://jdebp.eu./Proposals/DebianPolicy/ch-opersys.html#s-systemdandupstartandrc

* https://jdebp.eu./Proposals/DebianPolicy/ch-opersys.html#s9.3.1.2
* https://jdebp.eu./Softwares/nosh/guide/invoke-rc.d.html
* http://manpages.ubuntu.com./manpages/xenial/man8/invoke-rc.d.8.html

Don't use "stop" followed by "start" to enact a conditional restart 
after reconfiguration.  That unilaterally starts services if they 
weren't already running.  Use a single invocation with the verb 
"force-reload".  You can often also use "try-restart", or 
"condrestart".  The latter two are better, as a matter of fact, because 
Fedora defines "force-reload" differently to the LSB.  In the Fedora 
world, "force-reload" is supposed to actually start a service if it 
isn't currently running.


* 
https://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782993
* 
https://fedoraproject.org/w/index.php?title=Packaging:SysVInitScript&oldid=297366#Required_Actions


My shims are not the only places where verb translation happens. You 
have to do it, too, if you move between "invoke-rc.d"/"service" and 
other things.  systemd's own systemctl utility is not the same as the 
"service" command, for one thing.  It does not provide the LSB verb set, 
but a revised verb set of its own; one that has changed with time, too.  
For it, the (currently) correct verb here is "try-reload-or-restart", 
which attempts a reload, and if that is not possible does a restart, but 
only if the service is currently already running.  "condrestart" used to 
be available and documented as an alias for (what was then) the 
"reload-or-try-restart" verb, and later became an alias for the 
"try-restart" verb.  It has since been removed from the systemctl 
documentation altogether.  I haven't checked whether it is still 
actually there in the program.


* 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Services.html#tabl-Managing_Services_with_systemd-Services-systemctl
* 
https://lists.freedesktop.org/archives/systemd-devel/2010-September/000387.html
* 
https://lists.freedesktop.org/archives/systemd-devel/2010-November/000863.html

* https://bugzilla.redhat.com/show_bug.cgi?id=635780
* http://linuxmanpages.net/manpages/fedora16/man1/systemctl.1.html

nosh version 1.28

[Jonathan de Boyne Pollard]

The nosh package is now up to version 1.28 .

* https://jdebp.eu./Softwares/nosh/
* 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project

* http://jdebp.info./Softwares/nosh/

There's a lot in this one: MySQL and MariaDB changes; more prophylaxis 
for Desktop Bus bus activation; improvements to systemd unit conversion; 
support for the old svc -x; machineenv; improvements to service 
management; fixes for the per-user manager; improvements to the console 
terminal emulator; BSD boot mode changes; the ability to pass more open 
sockets to connection-accepting programs; cron; and OpenBSD.


Italics and colour
==

* https://jdebp.eu./Softwares/nosh/italics-in-manuals.html

This isn't a toolset change, per se.  But the WWW site now has a guide 
to seeing actual italic text in manual pages.  The nosh toolset's 
user-space virtual terminals support true italics (if one has the fonts) 
or obliquing, and this works with them.


MySQL and MariaDB changes
=

* https://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html

New in version 1.28 is a different and up-to-date way of managing MySQL 
and MariaDB server services — where "new" translates to finally getting 
rid of that unnecessary mysql_safe wrapper and doing things the way that 
daemontools-family toolset users have wanted to do them since the turn 
of the century.


There's a lengthy exposition on the WWW site, q.v..  The major visible 
effect is that your "mysql" or "mariadb" service is now an alias, for 
something like a "mysql@" or "mysql@01" (if you have [mysql01] in your 
my.cnf) service.  The configuration file import mechanism tries to 
construct/update mariadb@NN and mysql@NN service bundles for you, based 
upon your MariaDB and MySQL configuration files.


Further prophylaxis for Desktop Bus bus activation
==

* https://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html

The nosh toolset now comes with a dbus-daemon-launch-helper 
replacement.  The purpose of this is to sit in your 
/usr/local/etc/dbus-1/system.conf (or equivalent) and redirect to 
service management attempts, by the Desktop Bus broker daemon, to 
demand-start services.  It is slightly fiddly to install, requiring 
manual setup by the system administrator, there being no simple way to 
add overrides to /usr/local/etc/dbus-1/system.conf and it requiring that 
you allow the "messagebus" user the necessary access for starting and 
stopping services (but not necessarily *superuser* access — rembember ACLs).


To assist with this, several popular Desktop Bus "services" now exist as 
alias names for service management services.  These are just symbolic 
links to the service bundle directories, of course. So, for example: 
With the helper in place, Desktop Bus bus activation will try to 
demand-start a service named "org.freedesktop.PackageKit" using service 
management.  This is just an alias for the "packagekit" service.


Improvements to systemd unit conversion
===

Ideal mode is now closer to the daemontools-family mainstream, 
defaulting to the daemontools-family norm of always restarting 
services.  Quirks mode, conversely, now implements more of the 
non-daemontools redirection semantics for standard I/O, in particular 
with regard to listening socket units.  Some more Linuxisms have been 
added.  Limits (where applicable) can now take SI and IEC suffixes (so 
you can, say, express limits in kiloseconds).  This latter is actually 
an augmentation to the underlying softlimit command.


Passing more open sockets to connection-accepting programs
==

The improvements to systemd unit conversion also allow passing more than 
one listen()ing socket to connection-accepting programs.  You can use, 
say, ListenStream and ListenDatagram and the conversion utility will 
translate this into an appropriate chain of multiple invocations of 
udp-socket-listen and tcp-socket-listen.  It will do 
local-stream-socket-listen, local-datagram-socket-listen, 
netlink-datagram-socket-listen, and fifo-listen too.


The motivator for this was Daniel J. Bernstein's dnscache.  I have 
modified versions of tinydns, dnscache, and taiclockd that understand 
the LISTEN_FDS protocol for their being told about listening sockets 
that have been opened for them, and don't open their own sockets in that 
case.  dnscache, in particular, takes a UDP socket and a listening TCP 
socket.  The UCSPI tools in this version of the toolset can now provide 
these two to a dnscache process.  One simply chains through 
udp-socket-listen and tcp-socket-listen to dnscache, using the 
--systemd-compatibility flag.


The sharp-eyed will notice that the tinydns and dnscache services are 
following in the footsteps of the mariadb and mysql services, being 
instantiated for relevant IP addresses by the configuration import 
subsyst

Re: Re: How to prevent /tmp files from being deleted at reboot

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:

Untrue. The OpenRC people have had a tmpfiles utility since 2012.


Michael Biebl:

I didn't know that. Thanks for the info.
Can you post some more details? Where can I find the sources for that?
Is it packaged for Debian?



Here's the Gentoo OpenRC repository:

* https://gitweb.gentoo.org/proj/openrc.git/log/sh/tmpfiles.sh.in

Here's a mirror:

* https://github.com/OpenRC/openrc

Here are the Debian packages:

* https://tracker.debian.org/pkg/openrc

How to prevent /tmp files from being deleted at reboot

[Jonathan de Boyne Pollard]

Michael Biebl:

There are 3 kind of "timestamps":
 Access - the last time the file was read
 Modify - the last time the file was modified (content has been modified)
 Change - the last time meta data of the file was changed (e.g. permissions)


Not on all flavours of Debian.  Debian FreeBSD has 4.

* http://superuser.com/a/703927/38062

How to prevent /tmp files from being deleted at reboot

[Jonathan de Boyne Pollard]

Michael Biebl: > Strictly speaking, the tmpfiles.d mechanism is not tied 
to a particular init. It's just that no-one has provided an 
implementation for non-systemd.


Untrue. The OpenRC people have had a tmpfiles utility since 2012.

nosh and redo have moved

[Jonathan de Boyne Pollard]

The whole sorry tale of why is on the new WWW site.  The upshot of it is 
that nosh and redo are in a new place.


* https://jdebp.eu./Softwares/nosh/

** https://jdebp.eu./Softwares/nosh/source-package.html

** https://jdebp.eu./Softwares/nosh/freebsd-binary-packages.html

** https://jdebp.eu./Softwares/nosh/debian-binary-packages.html

* https://jdebp.eu./Softwares/redo/

Re: how to make systemd execute init.d script status statements?

[Jonathan de Boyne Pollard]

Looks like systemd does not execute the statements in status) case of the init script 
at all, but just checks if the daemon process exists. My '/etc/init.d/ status' did much more, i.e., it checked if the daemon was actually able to 
do some real work.

So far I have had no luck in finding the answer from the web.


You will find the answer here:

* 
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/unix-daemon-readiness-protocol-problems.html

* https://freedesktop.org/software/systemd/man/sd_notify.html
* https://freedesktop.org/software/systemd/man/systemd-notify.html
* 
https://lists.freedesktop.org/archives/systemd-devel/2014-April/018797.html


If you want to make your daemon interoperate with systemd's status 
mechanism to the extent of having custom status reports, you have to 
modify your daemon to send readiness notification messages through a 
socket to the systemd service manager.  That way, not only will 
"/etc/init.d/jh status" report your custom statuses, so too will 
"systemctl status jh" and (possibly) so too will (some) GUI 
administration tools.


To do this, you must write a service unit for your service. Sticking 
with a van Smoorenbug rc script and relying upon the 
systemd-sysv-generator to write a compatibility service unit on the fly 
to encapsulate it won't work, for several reasons.  For starters, the 
generator doesn't generate Type=notify service units and uses 
RemainAfterExit=true (which prevents detection of service abends).