Re: [DNG] use zram for /tmp - how?

[emninger]

Am Sat, 04 Jun 2016 21:14:23 +
schrieb Florian Zieboll :

> just guessing as I am usually rather low on ram... following the
> debian wiki link, for a first try i'd adapt the $SIZE and replace the
> mkswap/swapon lines of the script with "mount /dev/zram$i /tmp" and
> comment out the stop/swapoff part. of course the ramdisk will have to
> be mounted before /tmp is used...

Thanks Florian! That might be an idea - if it is not working the other
way around: like parazyd suggested. May be raise the space of zram swap
and set then tmpfs (which should then, if i understand it correctly,
should use the mem including the virtual mem/swap) ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] man init

[Arnt Karlsen]

On Sat, 4 Jun 2016 16:58:24 +0100, KatolaZ wrote in message 
<20160604155824.gw32...@katolaz.homeunix.net>:

> On Fri, Jun 03, 2016 at 09:10:05PM -1000, Joel Roth wrote:
> > My system is devuan/jessie, upgraded from debian.
> > 
> > It's interesting that 'man init' brings up the 
> > systemd man page.
> > 
> 
> All my systems were upgraded from Debian Wheezy/Jessie, and man init
> is about sysvinit.
> 
> HND
> 
> KatolaZ
> 


..my first conversion is sid/stretch -> ceres 
root@celsius:~# dpkg -l |grep systemd |cut -d" " -f -55 |fmt -tu
ii dh-systemd 1.29+devuan1.0
ii gnome-logs 3.20.1-1
ii libconfig-model-systemd-perl 0.006-1
ii libsystemd0:amd64 230-2
ii systemd-shim 9-1
root@celsius:~# 

..and I still have 'man init' starting:"
INIT(8)
Linux System Administrator's
Manual
INIT(8)

NAME
   init, telinit - process control initialization

SYNOPSIS
   /sbin/init [ -a ] [ -s ] [ -b ] [ -z xxx ] [ 0123456Ss ]
   /sbin/telinit [ -t SECONDS ] [ 0123456sSQqabcUu ]
   /sbin/telinit [ -e VAR[=VAL] ]

DESCRIPTION
"

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility (was: SoylentNews discussion)

[Steve Litt]

On Sat, 4 Jun 2016 22:06:47 +0100
Simon Hobson  wrote:

> Steve Litt  wrote:
> 
> > In all daemontools-inspired process supervisors, dependency
> > handling, if you indeed need it, is just this easy:
> > 
> > ==
> > #!/bin/sh
> > if ping ; then
> >  exec /path/to/app_depending_on_network
> > fi
> > sleep 1
> > ==
> > 
> > In the preceding, if the ping succeeds, the run script is replaced
> > by app_depending_on_network. If the ping fails, after 1 second the
> > run script finishes, at which time or soon after, daemontools will
> > try it again.  
> 
> There is an argument for doing everything that way. IIRC it was
> discussed in here, I know I've seen it discussed elsewhere, but there
> are inherent problems with the "classical" dependency model - namely
> that "ready" is often a nebulous thing, and may only be transient. A
> classic example of that is networking. When is "the network" ready ?
> When the first ethernet port is active ? When a WiFi port is active ?
> When a PPP link is up ? When you can actually ping "something on the
> internet" ? Something else ? 

With daemontools-inspired process supervisors, you'd just bake those
things into the if statement. When I say "you", ultimately I mean the
admin, because, as you say below:

> In the general case, it's absolutely not
> possible for a generic supervisor, running a generic config, to know
> that for every combination of networking that people could come up
> with. And of course, what if an interface goes down ? So logically,
> anything that relies on "networking" being active should have
> (probably installation specific) checks to determine for itself when
> there is sufficient networking available. 

And ultimately, the definition of "sufficient" rests with the admin,
because, as you mention, either the distro nor the "upstream" knows
about the admin's exact use case.

> And of course there are
> (these days) very often dependencies outside of the host that's
> starting up - eg no point starting the mail service if the back end
> database it needs isn't available.
> 
> So if every "something" was made responsible for working out when
> it's dependencies are met, startup sequencing becomes "fire up
> everything" and leave them to it.

Yes. That's pretty much what daemontools-inspired process supervisors
do. It sounded to me like it would be a football field of ping pong
balls mounted on mousetraps, and might take 10 minutes of trial and
error to get everything up, but in fact that didn't turn out to be the
case.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility (was: SoylentNews discussion)

[Florian Zieboll]

On Sat, 4 Jun 2016 19:41:02 +0100
Simon Hobson  wrote:

> Florian Zieboll  wrote:
> 
> > Seriously, what else besides dependencies on other daemons that
> > have to be running and some testing for the existence of certain
> > (everything is) files would be necessary to pass to a parser
> > script, which could be packaged with the respective init system? 
> 
> Are we in danger of removing one of the great benefits of the shell
> scripts used by sysvinit - the ability to code pretty well anything
> that's needed. I realise that this also means the scripts can tend to
> "sprawl", but it gives great flexibility - including for local
> modifications.

hallo simon,

i was not talking about replacing sysvinit's shellscripts, but suggest
to implement a routine that creates them "on the fly" on installation
of a new daemon, from /one/ init-independent "meta" configuration file,
packaged with the daemon.

every init system would have its own routine to parse these meta files
into scripts or configuration files of its very own format. Hence there
will be no black box, local modifications are possible as usual - in
the best case it won't make any difference for the admin at all. 

depending on the respective init system, this routine could also be
used to (interactively) configure the behavior of individual daemons on
crashes (restart?) and ask for additional prerequisites or tests.

regarding your feedback about mysqld: don't you think its readiness
could be verified with an init-independent, zero-exiting command defined
in the above mentioned meta configuration file?

regards,

florian

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility (was: SoylentNews discussion)

[Simon Hobson]

Steve Litt  wrote:

> In all daemontools-inspired process supervisors, dependency handling,
> if you indeed need it, is just this easy:
> 
> ==
> #!/bin/sh
> if ping ; then
>  exec /path/to/app_depending_on_network
> fi
> sleep 1
> ==
> 
> In the preceding, if the ping succeeds, the run script is replaced by
> app_depending_on_network. If the ping fails, after 1 second the run
> script finishes, at which time or soon after, daemontools will try it
> again.

There is an argument for doing everything that way. IIRC it was discussed in 
here, I know I've seen it discussed elsewhere, but there are inherent problems 
with the "classical" dependency model - namely that "ready" is often a nebulous 
thing, and may only be transient.
A classic example of that is networking. When is "the network" ready ? When the 
first ethernet port is active ? When a WiFi port is active ? When a PPP link is 
up ? When you can actually ping "something on the internet" ? Something else ? 
In the general case, it's absolutely not possible for a generic supervisor, 
running a generic config, to know that for every combination of networking that 
people could come up with. And of course, what if an interface goes down ?
So logically, anything that relies on "networking" being active should have 
(probably installation specific) checks to determine for itself when there is 
sufficient networking available.
And of course there are (these days) very often dependencies outside of the 
host that's starting up - eg no point starting the mail service if the back end 
database it needs isn't available.

So if every "something" was made responsible for working out when it's 
dependencies are met, startup sequencing becomes "fire up everything" and leave 
them to it.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] use zram for /tmp - how?

[parazyd]

For /tmp I would definitely use tmpfs.
It's as simple as adding an entry to the fstab

tmpfs  /tmp  tmpfs  nodev,nosuid,size=2G  0 0

In this example, your /tmp will be 2 gigabytes big, but tmpfs will keep
your /tmp in RAM, while not cutting off the entire 2GB of your system's
RAM. It will only use as much as it needs.

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] use zram for /tmp - how?

[Florian Zieboll]

On Sat, 4 Jun 2016 21:44:37 +0200
 wrote:

> Anyone of you knows a way how to use zram for /tmp ?
> 
> (...)
> 
> I did not find anything for debian. Only zram for swap like here
> (https://wiki.debian.org/ZRam) and here
> (http://forum.linuxvillage.org/index.php?topic=92.0)


just guessing as I am usually rather low on ram... following the debian
wiki link, for a first try i'd adapt the $SIZE and replace the
mkswap/swapon lines of the script with "mount /dev/zram$i /tmp" and
comment out the stop/swapoff part. of course the ramdisk will have to
be mounted before /tmp is used...

f.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility (was: SoylentNews discussion)

[Steve Litt]

On Sat, 4 Jun 2016 11:49:25 +0200
Florian Zieboll  wrote:

> On Sat, 4 Jun 2016 03:27:16 -0400
> Steve Litt  wrote:
> 
> > On Sat, 4 Jun 2016 00:42:46 +0200
> > Florian Zieboll  wrote:
> >   
> > > My experience with init systems is mostly limited sysV init (well,
> > > also busybox and system d). That said, I wonder, what information
> > > any arbitrary init system would need, that can not be delivered
> > > e.g. in a simple XML file, packaged with the daemon.  
> > 
> > You never, never, NEVER want PID1 to be encumbered with an XML
> > parser. Unless you're OS/x (launchd). What could *possibly* go
> > wrong?  
> 
> 
> Hallo Steve,
> 
> you fully got me wrong here: I don't see the xml (or what ever) parser
> in the init system (aka pid1) itself, but to be called by the updating
> routines of the init systems, whenever an additional daemon gets
> installed. 

That's fine. Absolutely no problem doing that. In fact, it's a good
idea.

 
> In other words: ATM, every init system comes packaged with the
> necessary init scripts in their own "proprietary" format. I envision
> this information extracted from the individual init scripts 

I would never take on that assignment. Parsing out dependency info from
anything but systemd or Epoch would be a murderous task.

I think we should "mooch" info from the now ubiquitous systemd unit
files to set dependencies for other inits.

Either that, or just let them fly, and see what goes wrong. I've been
using Runit for 6 months now. Among supervised (respawned) processes,
there is no definition of order. Order is indeterminate. And yet,
nothing goes wrong. This is not the result I would have expected from
indeterminate process startup, but this is what happens.

In all daemontools-inspired process supervisors, dependency handling,
if you indeed need it, is just this easy:

==
#!/bin/sh
if ping ; then
  exec /path/to/app_depending_on_network
fi
sleep 1
==

In the preceding, if the ping succeeds, the run script is replaced by
app_depending_on_network. If the ping fails, after 1 second the run
script finishes, at which time or soon after, daemontools will try it
again.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] man init

[. fsmithred]

Another one you might lose when you remove libsystemd0 is gvfs, but maybe
you didn't install that to begin with.

I have to tell my laptop to suspend before I close the lid, otherwise,
nothing happens. It comes back automatically when I lift the lid.

-fsr

On Sat, Jun 4, 2016 at 2:27 PM, Joel Roth  wrote:

> On Sat, Jun 04, 2016 at 11:51:12AM +0200, Jaromil wrote:
> > On Fri, 03 Jun 2016, Joel Roth wrote:
> >
> > > My system is devuan/jessie, upgraded from debian.
> > >
> > > It's interesting that 'man init' brings up the
> > > systemd man page.
> >
> > strange! I don't have that on my laptop (installed from devuan
> > directly) but will check on other systems. curious why this occurs.
> > well spotted
>
> The reason was that systemd was still installed on my system
> after the upgrade, along with sysvinit.
>
> After removing systemd, I still had a couple of systemd
> related packages:
>
> ii  libsystemd0:amd64   215-17+deb8u4   amd64systemd utility
> library
> ii  systemd-shim9-1 amd64shim for systemd
>
> There weren't any dependencies for systemd-shim, so I got
> rid of that. libsystemd0 is needed by acpi-fakekey and
> sane-utils. I got rid of both. The latter is related to
> using a scanner.
>
> I notice my laptop won't sleep on closing the lid anymore.
>
> Oh, and 'man init' now returns the correct page.
>
> Cheers,
>
>
> > ciao
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
> --
> Joel Roth
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility (was: SoylentNews discussion)

[Simon Hobson]

Florian Zieboll  wrote:

> Seriously, what else besides dependencies on other daemons that have to
> be running and some testing for the existence of certain (everything is)
> files would be necessary to pass to a parser script, which could be
> packaged with the respective init system? 

Are we in danger of removing one of the great benefits of the shell scripts 
used by sysvinit - the ability to code pretty well anything that's needed. I 
realise that this also means the scripts can tend to "sprawl", but it gives 
great flexibility - including for local modifications.

So for example, a database init script can go further than just checking that 
the daemon has started, it can run specific queries against the database to 
determine that it's actually ready to serve queries before returning "started". 
I believe MySQL does this - hence a sprawling script.

For local modifications, it may be desirable to check that a service is running 
on a remote host before starting. For example, I have a small mail server 
cluster that uses a single policy daemon running on a backend machine - 
although I haven't done it, it would be fairly easy on the shell script to wait 
for that service to be available before starting Postfix.

While both of these could be handled with a set of "before starting", "after 
starting", etc type hooks to call external scripts - IMO we're then into an 
even worse situation where you have a config file feeding into the block box of 
hidden logic AND have one or more scripts containing exactly what people are 
criticising SysV for.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] man init

[Joel Roth]

On Sat, Jun 04, 2016 at 11:51:12AM +0200, Jaromil wrote:
> On Fri, 03 Jun 2016, Joel Roth wrote:
> 
> > My system is devuan/jessie, upgraded from debian.
> > 
> > It's interesting that 'man init' brings up the 
> > systemd man page.
> 
> strange! I don't have that on my laptop (installed from devuan
> directly) but will check on other systems. curious why this occurs.
> well spotted

The reason was that systemd was still installed on my system
after the upgrade, along with sysvinit.

After removing systemd, I still had a couple of systemd
related packages:

ii  libsystemd0:amd64   215-17+deb8u4   amd64systemd utility library
ii  systemd-shim9-1 amd64shim for systemd

There weren't any dependencies for systemd-shim, so I got
rid of that. libsystemd0 is needed by acpi-fakekey and
sane-utils. I got rid of both. The latter is related to 
using a scanner.

I notice my laptop won't sleep on closing the lid anymore.

Oh, and 'man init' now returns the correct page.

Cheers,

 
> ciao
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Swoosh for .signature

[KatolaZ]

Well, I don't know how many of us still use the old-fashioned 4/5
lines .signature, but who happens to have one and use Devuan could
find this 5-lines swoosh useful, and those more versed in ascii-arts
might actually be inspired to produce a cool one:

 ~.,_  
 "+.
   @) 
 @@) 
 (@@@)  


Beware: if you don't use a fixed-size font, you won't see any swoosh
above. But in that case you wouldn't care that much about an ascii
swoosh anyway... :)

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  GNU/Linux User: #325780  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  @KatolaZ -- jab: kato...@jabber.org -- skype: katolaz  ]   
  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] man init

[KatolaZ]

On Fri, Jun 03, 2016 at 09:10:05PM -1000, Joel Roth wrote:
> My system is devuan/jessie, upgraded from debian.
> 
> It's interesting that 'man init' brings up the 
> systemd man page.
> 

All my systems were upgraded from Debian Wheezy/Jessie, and man init
is about sysvinit.

HND

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] SoylentNews discussion

[Didier Kryn]

Le 04/06/2016 17:11, Dan Purgert a écrit :

I think you misinterpreted my 'on the fly' comment.  I didn't mean at
boot time, but rather at install / setup.  That is, add an "init system"
choice along with "desktop: Mate/XFCE/etc.", "print server", "ssh
server" [...]


Ideed, I did misinterpret your comment :-)

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] SoylentNews discussion

[Dan Purgert]

Didier Kryn wrote:
> Le 03/06/2016 19:31, Dan Purgert a écrit :
> >Is it possible during setup to choose the init system on the fly?  I
> >mean, we can choose Cinnamon / Mate / xfce / etc for the DE as it is (or
> >all of them - although I expect having multiple competing init binaries
> >is bad).
> 
> Yes, it is possible. I can see two methods to choose the init system on
> the fly:
> 
> Through the kernel's command-line 'init=foo' (might be implemented in
> grub config)
> 
> By making init a simple script offering interactively the choice of a
> true init to the user, with timeout and default, on the console, and then
> execing the selected init.

I think you misinterpreted my 'on the fly' comment.  I didn't mean at
boot time, but rather at install / setup.  That is, add an "init system"
choice along with "desktop: Mate/XFCE/etc.", "print server", "ssh
server" [...]

> 
> Didier
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] man init

[Didier Kryn]

Le 04/06/2016 14:00, Nate Bargmann a écrit :

* On 2016 04 Jun 04:52 -0500, Jaromil wrote:

On Fri, 03 Jun 2016, Joel Roth wrote:


My system is devuan/jessie, upgraded from debian.

It's interesting that 'man init' brings up the
systemd man page.

strange! I don't have that on my laptop (installed from devuan
directly) but will check on other systems. curious why this occurs.
well spotted

On this desktop upgraded from Debian Jessie to Devuan Jessie about a
month ago, 'man init' gives me the page for sysvinit.  Only libsystemd0
is installed.  Any other search for systemd shows uninstalled packages.

- Nate


Same as Nate on a fresh install of Beta two weeks ago.

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] man init

[Nate Bargmann]

* On 2016 04 Jun 04:52 -0500, Jaromil wrote:
> On Fri, 03 Jun 2016, Joel Roth wrote:
> 
> > My system is devuan/jessie, upgraded from debian.
> > 
> > It's interesting that 'man init' brings up the 
> > systemd man page.
> 
> strange! I don't have that on my laptop (installed from devuan
> directly) but will check on other systems. curious why this occurs.
> well spotted

On this desktop upgraded from Debian Jessie to Devuan Jessie about a
month ago, 'man init' gives me the page for sysvinit.  Only libsystemd0
is installed.  Any other search for systemd shows uninstalled packages.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility (was: SoylentNews discussion)

[Florian Zieboll]

On Sat, 4 Jun 2016 03:27:16 -0400
Steve Litt  wrote:

> On Sat, 4 Jun 2016 00:42:46 +0200
> Florian Zieboll  wrote:
> 
> > My experience with init systems is mostly limited sysV init (well,
> > also busybox and system d). That said, I wonder, what information
> > any arbitrary init system would need, that can not be delivered
> > e.g. in a simple XML file, packaged with the daemon.
> 
> You never, never, NEVER want PID1 to be encumbered with an XML parser.
> Unless you're OS/x (launchd). What could *possibly* go wrong?


Hallo Steve,

you fully got me wrong here: I don't see the xml (or what ever) parser
in the init system (aka pid1) itself, but to be called by the updating
routines of the init systems, whenever an additional daemon gets
installed. 

In other words: ATM, every init system comes packaged with the necessary
init scripts in their own "proprietary" format. I envision this
information extracted from the individual init scripts and put into an
init independent, "per daemon" config file, which is parsed at
installation time (not at boot time!) by a "per init system" script to
create the then static init scripts.

So I'm pointing into a similar direction as Peter Olson did earlier
today in the "SoylentNews discussion" thread: 

| On Sat, 4 Jun 2016 02:35:54 -0400 (EDT) 
| Peter Olson  wrote:
| 
| It's a difficult issue, but maybe solvable by parsing common idioms
| of each init system into a description of the init process.
| 
| Some of this may be automatic, but Turing says it cannot be done
| entirely by machine.  It would be nice to make a lot of parsing
| automatic and only require human intervention for the difficult cases.
| 
| I don't have a specific idea of how to do this.
| 
| The resulting idea is to transform the parsed description into files
| for each of the kinds of init.
| 
| Difficult issues could be submitted as feature requests upstream.


I saw your mail from tonight (Fri, 3 Jun 2016 18:17:34 -0400), also in
the "SoylentNews discussion" thread, which more or less overlapped with
my previous mail, so I realize that there are more challenges to solve
than telling the init system when and how to fire up which daemon... 

Regards from within the new central european monsoon,

Florian

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] man init

[Jaromil]

On Fri, 03 Jun 2016, Joel Roth wrote:

> My system is devuan/jessie, upgraded from debian.
> 
> It's interesting that 'man init' brings up the 
> systemd man page.

strange! I don't have that on my laptop (installed from devuan
directly) but will check on other systems. curious why this occurs.
well spotted

ciao
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility

[Didier Kryn]

Le 04/06/2016 09:34, Simon Walter a écrit :

On 06/04/2016 04:27 PM, Steve Litt wrote:
I always feel a lot better when I can singlehandedly fix what goes 
wrong with my possessions.


Here here! Give this man a beer! I usually use both hands, but I do 
know what you mean.

___


Then one hand is taken to hold the beer.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] SoylentNews discussion

[Didier Kryn]

Le 04/06/2016 08:16, KatolaZ a écrit :

The problem is not in the way we should tell the kernel which is the
process that will run as PID 1, but in managing the configuration
scripts used by different init systems in a comprehensive,
sustainable, and maintainable way, and in letting them possibly
coexist in the same system.

My2Cents

KatolaZ


I agree that the question you say is the most discussed in the 
thread, but the question I answered here was more technical, and from 
the point of view of experimentation, and I replied to the later.


But it makes sense also for the point of view of managing the 
configuration. I insist that several init systems could coexist on the 
same host and for the same OS, in an even more versatile way than what 
is done currently for the DE.


For the DE, you can choose the one in function, eg xfce4, but, even 
as root and from the console, you cannot start another one for one shot. 
Only the "default" one can be run, at least using the standard startup 
command.


For the init system, since the kernel accepts the argument 
'init=foo', you can, in principle, configure grub to offer a choice. You 
merely need to configure which one is the default and this comes 
naturally along with grub's default.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility

[Simon Walter]

On 06/04/2016 04:27 PM, Steve Litt wrote:
I always feel a lot better when I can singlehandedly fix what goes 
wrong with my possessions.


Here here! Give this man a beer! I usually use both hands, but I do know 
what you mean.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility (was: SoylentNews discussion)

[Steve Litt]

On Sat, 4 Jun 2016 03:27:16 -0400
Steve Litt  wrote:


> Now I'm going to wander into the realm of pure opinion, and please
> understand, I am not, not, NOT suggesting Devuan ever officially
> incorporate this...

Whoops, I forgot the URL: http://ewontfix.com/14/

The author is Rich Felker, and this is my opinion of what an init
system should ideally look like.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] man init

[Steve Litt]

On Fri, 3 Jun 2016 21:10:05 -1000
Joel Roth  wrote:

> My system is devuan/jessie, upgraded from debian.
> 
> It's interesting that 'man init' brings up the 
> systemd man page.
> 

I thought you were supposed to run manctl init so that the mand process
could write its binary man journal which you manctl could make human
readable.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Init compatibility (was: SoylentNews discussion)

[Steve Litt]

On Sat, 4 Jun 2016 00:42:46 +0200
Florian Zieboll  wrote:


> My experience with init systems is mostly limited sysV init (well,
> also busybox and system d). That said, I wonder, what information any
> arbitrary init system would need, that can not be delivered e.g. in a
> simple XML file, packaged with the daemon.

You never, never, NEVER want PID1 to be encumbered with an XML parser.
Unless you're OS/x (launchd). What could *possibly* go wrong?

> 
> Seriously, what else besides dependencies on other daemons that have
> to be running and some testing for the existence of certain
> (everything is) files would be necessary to pass to a parser script,
> which could be packaged with the respective init system? 
> 
> Somewhat stunned,

Hi Florian,

You've taken this discussion deep enough that the definition of "init
system" becomes relevant.

Up until your question, init system discussions have pretty much
divided things into the monolithically entangled April Fools
Architecture systemd, and all other inits, which are fairly sane.

You're going deeper.

I'm going to reveal my bias right now. I think an init system should
look like this:

The author, Rich Felker, contends that PID1 should do nothing but fork
off a shellscript (the rc file) and sit there spinning around handling
signals. The rc file, which is NOT part of PID1, calls the software
that handles process management or process supervision (the latter
being the name we call things that respawn and don't expect the daemon
to put itself in the background).

I've read some of the writings of Laurent Bercot, author of s6 and
s6-rc, and if I understand him right, Laurent doesn't like the Felker
model because if the process handling the rc shellscript dies and
there are no terminals surviving, you're left with a dead machine whose
PID1 is still spinning merrily along. He's right about that, but it's
not a problem I'd personally worry too much about. But then again, I'm
not running a server bringing in $100K revenue a day.

If you're advocating putting an XML parser in something spawned by the
rc shellscript, hey, I'm fine with that. I'd do it differently, but
we're talking minor differences. If you're talking about putting it in
PID1, well, that's why we all deserted systemd: PID1 shouldn't have
that crap.

I personally think that the system of processes having provides and
needs is brilliant. I don't think it's ever been executed well, but the
idea is great. With provides and needs, it's probably pretty easy to
figure out run order, or with the daemontools-inspired process
supervisors, run script dependency checks. I think this is what you
were getting at with the XML idea.

There are two points of view on converting provides and needs to
process order: Fixed, where it's calculated ahead of time and turned
into a process startup order, and on boot, where the process starting
order gets done at boot time. Poettering favors the latter. I prefer the
former so that my boot is guaranteed determinate and I know the process
instantiation order.

Either way, as long as that stuff gets done outside of PID1, I'm happy.

Now I'm going to wander into the realm of pure opinion, and please
understand, I am not, not, NOT suggesting Devuan ever officially
incorporate this...

Regardless of your OS, regardless of your init system, regardless of
your distro, you can really take charge of your computer by moving some
of the process management out of your init system and into a dedicated
process supervisor like daemontools-encore, runit (used as a non-PID1),
and s6. Every process you move out of sysvinit or OpenRC and into
something like s6 is one more 100 line init script you can ignore. It's
one more set of magic order-defining comments you don't need.

Before I ever heard of systemd, I was using daemontools to run some of
my processes, just so I'd know what was under the hood, and I could
work on them. After all, the sysvinit/upstart combination that existed
before systemd wasn't all that understandable.

In the early days of the systemd controversy, I thought I'd just go
with systemd, and one by one remove control of processes from systemd
and give them to daemontools-encore or s6. 

You know how old I am? My first car (1959 Plymouth that I bought for
$150) had a flat head 6 engine on which you could do a tune-up in 20
minutes with a pliers, adjustable wrench, an emery board and a gapping
tool. Do you know how NICE that was? I could do almost anything on that
car if it didn't require a lift.

I look in the engine compartment of my Jeep Patriot and know the most
technical thing I'll ever do to it is fill the coolant. Everything's
all interconnected. I like my Jeep's gas mileage and the fact that it
doesn't burn a quart of oil every 50 miles, but man, I miss my Plymouth.

The more you take your process control away from your init and hand it
over to the likes of daemontools-encore, Runit or s6, the more you feel
like your under the hood of a 1959 

[DNG] man init

[Joel Roth]

My system is devuan/jessie, upgraded from debian.

It's interesting that 'man init' brings up the 
systemd man page.

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] SoylentNews discussion

[KatolaZ]

On Sat, Jun 04, 2016 at 08:00:43AM +0200, Didier Kryn wrote:

[cut]

> 
> Yes, it is possible. I can see two methods to choose the init
> system on the fly:
> 
> Through the kernel's command-line 'init=foo' (might be
> implemented in grub config)
> 
> By making init a simple script offering interactively the choice
> of a true init to the user, with timeout and default, on the
> console, and then execing the selected init.
> 

The problem is not in the way we should tell the kernel which is the
process that will run as PID 1, but in managing the configuration
scripts used by different init systems in a comprehensive,
sustainable, and maintainable way, and in letting them possibly
coexist in the same system.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] SoylentNews discussion

[Didier Kryn]

Le 04/06/2016 00:17, Steve Litt a écrit :

Alternately, the init= in grub could be changed, but this is a
GARGANTUAN pain in the butt to do every time.
Grub2 is, to me, a very complicated beast, but I think it is still 
capable of the tweaking which were possible with legacy grub. It should 
be possible to have an entry per os and per init system.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] SoylentNews discussion

[Didier Kryn]

Le 03/06/2016 19:31, Dan Purgert a écrit :

Is it possible during setup to choose the init system on the fly?  I
mean, we can choose Cinnamon / Mate / xfce / etc for the DE as it is (or
all of them - although I expect having multiple competing init binaries
is bad).


Yes, it is possible. I can see two methods to choose the init 
system on the fly:


Through the kernel's command-line 'init=foo' (might be implemented 
in grub config)


By making init a simple script offering interactively the choice of 
a true init to the user, with timeout and default, on the console, and 
then execing the selected init.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng