nosh with Debian's sysstat package
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
nosh packaged for Arch Linux
Someone: I am trying to create one or multiple packages for Archlinux to install nosh This has come up several times with multiple people, now. I have no Arch Linux machines, and I am entirely dependent from Arch Linux people for the packaging part. As I already told one person back in August 2016, this is your opportunity to shine. (-: My second redo is already packaged for Arch, I am told: * https://aur.archlinux.org/packages/redo-jdebp/ * https://git.parabola.nu/abslibre.git/plain/pcr/jdebp-redo/ Here's what I know. The redo packaging runs package/compile followed by package/export. This is not the way to approach packaging the nosh toolset. It's not one giant lump, as you can see from the FreeBSD/TrueOS, Debian, and OpenBSD packages that I have done. What you Arch Linux people with the packaging experience have to provide is a way, on Arch, for one source package to build multiple binaries packages. This should not be hard. It's a very common thing to do, after all. It is, indeed, pretty much the norm in the worlds of Debian and Ubuntu. As you can see from the WWW pages about the FreeBSD/TrueOS, Debian, and OpenBSD packages, there are doco packages, service bundle packages, multiple toolset packages, and multiple -run packages. The way that this works on Debian and the BSDs is largely driven by package/debian/rules and package/bsd/rules, which are in turn determined by Debian's package build system, in particular its dpkg-buildpackage tool. Notice what the rules system does. It runs package/export to populate the ./debian/tmp/ tree, and then package/stage to populate the individual binary package trees (with links) from that in the layout that is actually used within the packages. The Debian Maintainers' Guide and the FreeBSD Porters' Handbook have more on the concept of "staging" when building binary packages. * https://www.debian.org/doc/manuals/maint-guide/build.en.html#completebuild * https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/special.html#staging Coming up with how something like this works on Arch is another part of your opportunity to shine, Arch packaging people. Note that I currently plan to take package/export out of the build process and have package/stage work directly from (a copy of) the original slashpackage tree, i.e. command/ manual/ config/ guide/ et al.. Rearranging everything from slashpackage into another layout under ./debian/tmp/ only in order to rearrange it again in the staging areas seems like an unnecessary complexity. pax -r -w of the original slashpackage layout into ./debian/tmp/ or ./bsd/tmp/ seems a better idea. There has been for a fair while now an important note at http://jdebp.eu./Softwares/nosh/source-package.html that the package/export command may change. It does both too much and too little as a tool for installing from source. It exports one giant lump, and it doesn't do all of the things that the package "maintenance scripts" do. In pursuit of that latter, back in 1.29 the BSD side of package creation was modified to make it possible to auto-generate installation/upgrade/deinstallation scripts for the old and new BSD package tools. This is, as you can see, done with package/bsd/gencontrol, which makes (the very different) +MANIFEST files for both the old and new BSD package tools. This is on the cards for Debian as well. For Arch, the build system will need to process a similar set of files to the various package/bsd/nosh-*.p files, in some way that is appropriate to how such maintenance scripts are handled on Arch, as well as do more specific things for likes of nosh-run-system-manager. Yes, this is vague. I've refactored this into a way of making different maintenance scripts from effectively non-imperative lists of service bundles and user accounts. I'll press on with getting you a set of package/debian/nosh-*.p files, which at least will list the Linux service bundle suite not the BSD one, which can then be patched into arch/*.p files. You have to work out how to then join these lists up with however Arch does installation/upgrade/deinstallation scripts in packages, however. This is another part of your opportunity to shine, Arch packaging people.
Re: nosh version 1.31
2017-01-22 14:29 GMT-03:00 Guillermo: > > $ tai64nlocal /run/system-manager/log/current > [...] > 2017-01-21 22:11:17.709678664 system-manager: ERROR: > /sys/fs/cgroup/systemd//cgroup.subtree_control: No such file or > directory > 2017-01-21 22:11:17.709683364 system-manager: ERROR: > /sys/fs/cgroup/systemd//service-manager.slice/cgroup.subtree_control: > No such file or directory Yeah, writing to cgroup.subtree_control to enable or disable controllers for a hierarchy is v2-only; for cgroups v1, controllers are attached to a hierarchy by passing their names as mount options. And that creates a related issue: system-manager does the C++ equivalent of 'mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd', i.e. the hierarchy rooted in /sys/fs/cgroup/systemd doesn't have cgroup controllers attached, so subdirectories won't have any 'knobs' for set-control-group-knob(1) to act on: $ cat /proc/self/cgroup 1:name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service $ ls /sys/fs/cgroup/systemd/service-manager.slice/ttylogin\@.service/ttylogin\@tty1.service cgroup.clone_children cgroup.procs notify_on_release tasks If one mounts another cgroup hierarchy with attached controllers, for example with 'mount -t cgroup -o cpu cgroup /sys/fs/cgroup/cpu', the corresponding knobs won't be in the directory set-control-group-knob expects to find them: $ cat /proc/self/cgroup 2:cpu:/cgroup-in-cpu-hierarchy 1:name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service $ ls /sys/fs/cgroup/cpu/cgroup-in-cpu-hierarchy cgroup.clone_children cgroup.procs cpu.shares notify_on_release tasks $ cat /sys/fs/cgroup/cpu/cgroup-in-cpu-hierarchy/cpu.shares 1024 $ set-control-group-knob cpu.shares 2048 set-control-group-knob: FATAL: /service-manager.slice/ttylogin@.service/ttylogin@tty1.service/cpu.shares: No such file or directory One could instead attach controllers to the hierarchy rooted in /sys/fs/cgroup/systemd, for example by mounting it with 'mount -t cgroup -o cpu,name=systemd cgroup /sys/fs/cgroup/systemd' (not with system-manager as process 1), and things would appear to be OK: $ ls /sys/fs/cgroup/systemd/service-manager.slice/ttylogin\@.service/ttylogin\@tty1.service cgroup.clone_children cgroup.procs cpu.shares notify_on_release tasks (i.e. there is now a 'cpu.shares' file) But then set-control-group-knob (and also move-to-control-group I believe) becomes a no-operation because it can't find the cgroups hierarchy; function calls like read_my_control_group(self_cgroup, "name=systemd", current) in source/set-control-group-knob.cpp and source/move-to-control-group.cpp will return false because /proc/self/cgroup doesn't have the expected format: $ cat /proc/self/cgroup 1:cpu,name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service (The text between the colons now also contains the cgroup controller name, not just the 'name=systemd' part) $ set-control-group-knob cpu.shares 2048 $ cat /sys/fs/cgroup/systemd/service-manager.slice/ttylogin@.service/ttylogin@tty1.service/cpu.shares 1024 $ set-control-group-knob non-existent-knob 2048 (No output, not even a 'No such file or directory' error). G.
