Re: libinit idea

[Slawa Olhovchenkov]

On Mon, Feb 24, 2014 at 10:00:57AM -0800, Don Lewis wrote:

> I forgot to mention that the command line tools are feel cumbersome.  To
> restart a service:
>   FreeBSD:   /etc/rc.d/foo restart

service foo restart

>   Old Linux: /etc/init.d/foo restart

service foo restart

>   Systemd:   systemctl restart foo.service
> seems worse that that when I'm actually typing it ...
> 
> > Would it take seemingly forever?
> > 
> > I would like to try systemd in Linux, can't say at this stage whether
> > I'll like it, hate it, or somewhere in between.
> 
> There's no substitute for firsthand experience.
> 
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Nikolai Lifanov]

On 02/24/14 13:00, Don Lewis wrote:
> On 24 Feb, Thomas Mueller wrote:
>> from Don Lewis:
>>
>>> I've got a Fedora server here that has systemd and I've come to
>>> dislike it.  It seems to be one of those "Do not open.  No user
>>> serviceable parts inside." sorts of things.
>>   
>>> I was never able to get it to start NUT properly.
>>   
>>> More often than not, it fails to come up multi-user.  The machine has
>>> a large number of disks (mostly JFS and XFS) attached to it, and even
>>> after what I think should be a clean shutdown, it seems to want to
>>> fsck a bunch of them. Unfortunately, there seems to be some sort of
>>> timeout on that, so a bunch get skipped and then don't get mounted. 
>>> I have to manually fsck everything in single user mode.  Then if I
>>> reboot, it
>>> *might* come up properly.  I haven't been able to find any knobs to
>>> adjust the timeout.  Sometimes, there is just a message that says
>>> something like "an error occurred" at the top of the screen, just
>>> before the prompt for the single-user password, with no clue as to
>>> what it is unhappy about.
>>
>>> Emergency shutdown can also be a problem.  If I'm around when the
>>> power fails, I manually try to shut down the machine before the UPS
>>> battery runs down.  I don't have the screen on the UPS, so I hit the
>>> power button and cross my fingers that the machine will make it
>>> through the clean shutdown sequence in time.  It seems to take
>>> forever (many minutes) and I have no idea what the heck it is
>>> spending all of its time on.
>>
>>> The documentation seems to be very sparse.
>>
>>> My plan is to migrate this function to a FreeBSD server.
>>
>> This looks scandalously slow.  It reminds me of the time with OS/2
>> Warp 4 in the late 1990s when I had to close Netscape web browser in
>> preparation for shutdown, and it took 15 minutes because it was a hog
>> for memory, by late 1990s standards.  I had 20 MB RAM, not bad for
>> those days.
>>
>> What would happen if you typed at the command prompt
>> shutdown -r now
>> or
>> shutdown -p now
>> ?
>> Would it take seemingly forever?
> 
> In Linux-land "shutdown -h now" does what our "shutdown -p now" does.
> For whatever reason, doing shutdown that way seems faster.  That's not
> so handy for me in the power loss case because the machine is running X
> and is most likely sitting in the screensaver.  Switching to another
> vty, doing a root login, and typing in the shutdown command is a lot of
> typing to get right while flying blind without a monitor.
> 
> There might also be a slowdown due to the network being down, though
> it's hard to tell in my case.  I'm also not using NFS, which would be
> the obvious culprit.
> 
> I forgot to mention that the command line tools are feel cumbersome.  To
> restart a service:
>   FreeBSD:   /etc/rc.d/foo restart
>   Old Linux: /etc/init.d/foo restart
>   Systemd:   systemctl restart foo.service
> seems worse that that when I'm actually typing it ...
> 

The Handbook-recommended invocation, which also works on linux, is
"service foo restart".

>> Would it take seemingly forever?
>>
>> I would like to try systemd in Linux, can't say at this stage whether
>> I'll like it, hate it, or somewhere in between.
> 
> There's no substitute for firsthand experience.
> 

- Nikolai Lifanov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Don Lewis]

On 23 Feb, David Chisnall wrote:

> 5) In a world where we're moving towards sandboxing services via
> Capsicum, the service launcher needs to be able to create services
> with a potentially large set of initial file descriptors (including a
> socket to Casper), based on the configuration policy.

I don't think we want to lose the option of running the daemon in debug
mode in the foreground with extra verbosity sent to stdout/stderr and
possibly launched from gdb.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Don Lewis]

On 24 Feb, Thomas Mueller wrote:
> from Don Lewis:
> 
>> I've got a Fedora server here that has systemd and I've come to
>> dislike it.  It seems to be one of those "Do not open.  No user
>> serviceable parts inside." sorts of things.
>   
>> I was never able to get it to start NUT properly.
>   
>> More often than not, it fails to come up multi-user.  The machine has
>> a large number of disks (mostly JFS and XFS) attached to it, and even
>> after what I think should be a clean shutdown, it seems to want to
>> fsck a bunch of them. Unfortunately, there seems to be some sort of
>> timeout on that, so a bunch get skipped and then don't get mounted. 
>> I have to manually fsck everything in single user mode.  Then if I
>> reboot, it
>> *might* come up properly.  I haven't been able to find any knobs to
>> adjust the timeout.  Sometimes, there is just a message that says
>> something like "an error occurred" at the top of the screen, just
>> before the prompt for the single-user password, with no clue as to
>> what it is unhappy about.
> 
>> Emergency shutdown can also be a problem.  If I'm around when the
>> power fails, I manually try to shut down the machine before the UPS
>> battery runs down.  I don't have the screen on the UPS, so I hit the
>> power button and cross my fingers that the machine will make it
>> through the clean shutdown sequence in time.  It seems to take
>> forever (many minutes) and I have no idea what the heck it is
>> spending all of its time on.
> 
>> The documentation seems to be very sparse.
> 
>> My plan is to migrate this function to a FreeBSD server.
> 
> This looks scandalously slow.  It reminds me of the time with OS/2
> Warp 4 in the late 1990s when I had to close Netscape web browser in
> preparation for shutdown, and it took 15 minutes because it was a hog
> for memory, by late 1990s standards.  I had 20 MB RAM, not bad for
> those days.
> 
> What would happen if you typed at the command prompt
> shutdown -r now
> or
> shutdown -p now
> ?
> Would it take seemingly forever?

In Linux-land "shutdown -h now" does what our "shutdown -p now" does.
For whatever reason, doing shutdown that way seems faster.  That's not
so handy for me in the power loss case because the machine is running X
and is most likely sitting in the screensaver.  Switching to another
vty, doing a root login, and typing in the shutdown command is a lot of
typing to get right while flying blind without a monitor.

There might also be a slowdown due to the network being down, though
it's hard to tell in my case.  I'm also not using NFS, which would be
the obvious culprit.

I forgot to mention that the command line tools are feel cumbersome.  To
restart a service:
FreeBSD:   /etc/rc.d/foo restart
Old Linux: /etc/init.d/foo restart
Systemd:   systemctl restart foo.service
seems worse that that when I'm actually typing it ...

> Would it take seemingly forever?
> 
> I would like to try systemd in Linux, can't say at this stage whether
> I'll like it, hate it, or somewhere in between.

There's no substitute for firsthand experience.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Lucius Rizzo]

* Don Lewis  [2014-02-24 00:56]:
> On 23 Feb, Lucius Rizzo wrote:
> > * Andreas Nilsson  [2014-02-23 09:33]:
> >> Imho, the replacement to init and rc-scripts I sometimes think about
> >> would be to import SMF from opensolaris/illumos. There one can at
> >> least get the commands run and config used without looking at the
> >> source code.
> > 
> > I like SMF from Solaris 11 onwards and even SmartOS. However, I have
> > found to like systemd and use via systemctl on Arch far nicer than any
> > other rc scripts to date. 
> > 
> > Anyone care to share their thoughts on the pros and cons of something
> > like systemd the way Arch does?
> 
> I've got a Fedora server here that has systemd and I've come to dislike
> it.  It seems to be one of those "Do not open.  No user serviceable
> parts inside." sorts of things.

I had an entirely different experience - albeit on Arch. I had to use
systemd via systemctl for pretty much everything to build on the
machine. I use btrfs + linux-ck on Arch with systemd. In order to get
stuff to work, I had a pretty detailed  learning  experience with
systemd when I helped on the sendmail AUR port for Arch including
writing/enabling scripts to work with journald and systemd. 

Naturally, I'm somewhat surprised to see the the author's attitude
towards licensing and non-Linux support. Its rare to come across devs
who are zealous to such a degree. 

However, there seems to be an agreement at least in part to modernize or
optimize the boot-up/rc env in FreeBSD.

I don't know for most of you but for me, while this is interesting...I
almost never really reboot that often for me to actually see a real
advantage of a 3 sec boot-up difference by throwing away what we have and
migrating to something else. 

Which is why we should also consider more than just boot-up times -- for
me having a newer more intelligent way to manage rc environment might
bear more interest than a few second boot difference that I only see
once in a blue moon.

Though, now I am also at a point where I know commands in -
Debian/CentOS/Arch, BSD (FreeBSD/NetBSD) and Solaris 10/11/SmartOS (all
with different ways of doing thing). What's annoying is that each of
these OS/flavors have nuances in use of their rc scripts and while
^now^ it doesn't bother me at all, I imagine it may for a newb. 

In most cases, everything works. But when it doesn't, its  annoying to
remember svcadmin vs systemctl vs /etc/init.d vs service vs /etc/rc.d/
along with all the other commands just to check the logs...

-- 

| _o_ |_)o_ _  _  
|_|_|(_||_|_> | \|/_/_(_) - Lucius.Tel
--
++ New members are urgently needed in the Society for Prevention of ++
++  Cruelty to Yourself.  Apply within. ++
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Christian Laursen]

On 02/24/14 14:34, Andreas Nilsson wrote:

On Mon, Feb 24, 2014 at 2:25 PM, Matthias Gamsjager wrote:


How about delaying the startup of services that are not necessary right at
the start. For example sshd, samba etc could be loaded after xdm ( or even
after the DE has loaded).



On my core i5 with regular hdd I get:
23sec to boot kernel
13sec from mounted root to slim login promp.


I have not done any measurements here but this is what I experience as 
well. Once / has been mounted the rest of the startup doesn't take long.



Fixing the kernel boot time seems like a bigger gain, imho.


+1

--
Christian Laursen
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Andreas Nilsson]

On Mon, Feb 24, 2014 at 2:25 PM, Matthias Gamsjager wrote:

> On Mon, Feb 24, 2014 at 2:15 PM, Bruno Lauzé  wrote:
>
> > It's really good to read the comments and see people point of view on
> this
> > topic.
> > I totally agree RC system is really good and stable, easy and extensible.
> > The main concern I have here is performance. Starting a system is really
> > slow.
> > Boot to X (with simple xdm) is minimum 25 secs and I just feel there's
> > something to do to cut this delay.
> >
>
>
>
> How about delaying the startup of services that are not necessary right at
> the start. For example sshd, samba etc could be loaded after xdm ( or even
> after the DE has loaded).


On my core i5 with regular hdd I get:
23sec to boot kernel
13sec from mounted root to slim login promp.

Fixing the kernel boot time seems like a bigger gain, imho.

Best regards
Andreas
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[David Chisnall]

On 24 Feb 2014, at 13:25, Matthias Gamsjager  wrote:

> How about delaying the startup of services that are not necessary right at
> the start. For example sshd, samba etc could be loaded after xdm ( or even
> after the DE has loaded).

It's a good idea, but it depends on a far more complex system than our current 
rc.  

For example, what happens if you're mounting home directories over SMB?  You 
need to make sure that XDM doesn't complete the login until samba has started, 
which requires automounter / autofs integration with the init system.  You want 
to speculatively start samba (because you know a user is going to need it), but 
in such a way that you can delay directory lookup resolution until it's 
actually started.

There is a reason most systems are moving away from services started by a pile 
of shell scripts: the complex dependencies and event models that they must 
handle require some complex generic logic.  You can probably implement this in 
shell scripts, but it probably won't be fast and it definitely won't be 
maintainable.  

I would be fully in favour of importing a modern, flexible, service management 
framework into FreeBSD, but it needs some very careful design.  Launchd, 
systemd, SMF, and so on all have some good ideas, but none is quite the right 
fit for FreeBSD.

David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Matthias Gamsjager]

On Mon, Feb 24, 2014 at 2:15 PM, Bruno Lauzé  wrote:

> It's really good to read the comments and see people point of view on this
> topic.
> I totally agree RC system is really good and stable, easy and extensible.
> The main concern I have here is performance. Starting a system is really
> slow.
> Boot to X (with simple xdm) is minimum 25 secs and I just feel there's
> something to do to cut this delay.
>



How about delaying the startup of services that are not necessary right at
the start. For example sshd, samba etc could be loaded after xdm ( or even
after the DE has loaded).
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: libinit idea

[Bruno Lauzé]

It's really good to read the comments and see people point of view on this 
topic. 
I totally agree RC system is really good and stable, easy and extensible.
The main concern I have here is performance. Starting a system is really slow.
Boot to X (with simple xdm) is minimum 25 secs and I just feel there's 
something to do to cut this delay.




> Date: Sun, 23 Feb 2014 11:33:30 -0800
> From: list_free...@bluerosetech.com
> To: fjwc...@gmail.com
> Subject: Re: libinit idea
> CC: freebsd-current@freebsd.org
>
> On 2/23/2014 10:31 AM, Freddie Cash wrote:
>> The main developer for systemd is very anti-portability and anti-!Linux. He
>> had actively rejected patches that made his projects work on non-Linux
>> systems. In order to port systemd to a non-Linux system, he wants you to
>> first implement every Linux feature that systemd uses.
>>
>> systemd is a non-starter, and not with considering.
>
> It's pretty clear Lennart Poettering failed history.
>
> Perhaps the best examples of why systemd is an anti-pattern is this:
> systemd stores logs in a binary journal. After the Linux zealots have
> spent about two decades using binary system data storage as one of the
> reasons Windows sucks, that strikes me as particularly ironic.
>
> The RC system we have is proof you do not need anything more than bourne
> and a respectable amount of intelligence to design a good init system.
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>   
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Thomas Mueller]

from Don Lewis:

> I've got a Fedora server here that has systemd and I've come to dislike
> it.  It seems to be one of those "Do not open.  No user serviceable
> parts inside." sorts of things.
  
> I was never able to get it to start NUT properly.
  
> More often than not, it fails to come up multi-user.  The machine has a
> large number of disks (mostly JFS and XFS) attached to it, and even
> after what I think should be a clean shutdown, it seems to want to fsck
> a bunch of them. Unfortunately, there seems to be some sort of timeout
> on that, so a bunch get skipped and then don't get mounted.  I have to
> manually fsck everything in single user mode.  Then if I reboot, it
> *might* come up properly.  I haven't been able to find any knobs to
> adjust the timeout.  Sometimes, there is just a message that says
> something like "an error occurred" at the top of the screen, just before
> the prompt for the single-user password, with no clue as to what it is
> unhappy about.

> Emergency shutdown can also be a problem.  If I'm around when the power
> fails, I manually try to shut down the machine before the UPS battery
> runs down.  I don't have the screen on the UPS, so I hit the power
> button and cross my fingers that the machine will make it through the
> clean shutdown sequence in time.  It seems to take forever (many
> minutes) and I have no idea what the heck it is spending all of its time
> on.

> The documentation seems to be very sparse.

> My plan is to migrate this function to a FreeBSD server.

This looks scandalously slow.  It reminds me of the time with OS/2 Warp 4 in 
the late 1990s when I had to close Netscape web browser in preparation for 
shutdown, and it took 15 minutes because it was a hog for memory, by late 1990s 
standards.  I had 20 MB RAM, not bad for those days.

What would happen if you typed at the command prompt
shutdown -r now
or
shutdown -p now
?

Would it take seemingly forever?

I would like to try systemd in Linux, can't say at this stage whether I'll like 
it, hate it, or somewhere in between.

Tom
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Don Lewis]

On 23 Feb, Lucius Rizzo wrote:
> * Andreas Nilsson  [2014-02-23 09:33]:
>> Imho, the replacement to init and rc-scripts I sometimes think about
>> would be to import SMF from opensolaris/illumos. There one can at
>> least get the commands run and config used without looking at the
>> source code.
> 
> I like SMF from Solaris 11 onwards and even SmartOS. However, I have
> found to like systemd and use via systemctl on Arch far nicer than any
> other rc scripts to date. 
> 
> Anyone care to share their thoughts on the pros and cons of something
> like systemd the way Arch does?

I've got a Fedora server here that has systemd and I've come to dislike
it.  It seems to be one of those "Do not open.  No user serviceable
parts inside." sorts of things.

I was never able to get it to start NUT properly.

More often than not, it fails to come up multi-user.  The machine has a
large number of disks (mostly JFS and XFS) attached to it, and even
after what I think should be a clean shutdown, it seems to want to fsck
a bunch of them. Unfortunately, there seems to be some sort of timeout
on that, so a bunch get skipped and then don't get mounted.  I have to
manually fsck everything in single user mode.  Then if I reboot, it
*might* come up properly.  I haven't been able to find any knobs to
adjust the timeout.  Sometimes, there is just a message that says
something like "an error occurred" at the top of the screen, just before
the prompt for the single-user password, with no clue as to what it is
unhappy about.

Emergency shutdown can also be a problem.  If I'm around when the power
fails, I manually try to shut down the machine before the UPS battery
runs down.  I don't have the screen on the UPS, so I hit the power
button and cross my fingers that the machine will make it through the
clean shutdown sequence in time.  It seems to take forever (many
minutes) and I have no idea what the heck it is spending all of its time
on.

The documentation seems to be very sparse.

My plan is to migrate this function to a FreeBSD server.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Warner Losh]

On Feb 23, 2014, at 11:17 AM, David Chisnall  wrote:

> On 23 Feb 2014, at 18:11, Allan Jude  wrote:
> 
>> sysrc solves this nicely, it is in base now, and is great for
>> programmatically adding, removing and changing lines in rc.conf style
>> files. It is also in ports for older versions of FreeBSD where it is not
>> in base.
> 
> The problem is, there is no such thing as an rc.conf style file.  rc.conf is 
> just a shell script.  If you only edit it with sysrc, or you are careful to 
> preserve the structure, then it's fine.  There is absolutely nothing stopping 
> you, however, from writing arbitrarily complex shell scripts inside rc.conf.  
> Sure, it's a terrible idea to do so, but when has that ever stopped anyone?
> 
> An rc-replacement could enforce this by only accepting purely declarative 
> files for configuration, guaranteeing that if they were syntactically valid 
> they would also be machine editable, no matter what the user does to them.

We already have a rc.conf.default. Why not a rc.conf.automation that does that 
and is added to the list of things to source? Then things like sysrc could 
operation on that secure in the knowledge that no shell commands could be 
there, and all bets are off if someone edits it by hand?

Warner

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Allan Jude]

On 2014-02-23 17:04, Warner Losh wrote:
> 
> On Feb 23, 2014, at 11:17 AM, David Chisnall  wrote:
> 
>> On 23 Feb 2014, at 18:11, Allan Jude  wrote:
>>
>>> sysrc solves this nicely, it is in base now, and is great for
>>> programmatically adding, removing and changing lines in rc.conf style
>>> files. It is also in ports for older versions of FreeBSD where it is not
>>> in base.
>>
>> The problem is, there is no such thing as an rc.conf style file.  rc.conf is 
>> just a shell script.  If you only edit it with sysrc, or you are careful to 
>> preserve the structure, then it's fine.  There is absolutely nothing 
>> stopping you, however, from writing arbitrarily complex shell scripts inside 
>> rc.conf.  Sure, it's a terrible idea to do so, but when has that ever 
>> stopped anyone?
>>
>> An rc-replacement could enforce this by only accepting purely declarative 
>> files for configuration, guaranteeing that if they were syntactically valid 
>> they would also be machine editable, no matter what the user does to them.
> 
> We already have a rc.conf.default. Why not a rc.conf.automation that does 
> that and is added to the list of things to source? Then things like sysrc 
> could operation on that secure in the knowledge that no shell commands could 
> be there, and all bets are off if someone edits it by hand?
> 
> Warner
> 

This is basically what we do, we have puppet add:

rc_conf_files="/etc/rc.conf /etc/rc.conf.local /etc/rc.conf.scaleengine"

to rc.conf, and then we push our global config to the .scaleengine file

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Linux chasing (Was: libinit idea)

[Joe Nosay]

On Sun, Feb 23, 2014 at 3:50 PM, Lev Serebryakov  wrote:

> Hello, Freddie.
> You wrote 23 февраля 2014 г., 22:31:48:
>
> FC> The main developer for systemd is very anti-portability and
> anti-!Linux. He
> FC> had actively rejected patches that made his projects work on non-Linux
> FC> systems. In order to port systemd to a non-Linux system, he wants you
> to
> FC> first implement every Linux feature that systemd uses.
> FC> systemd is a non-starter, and not with considering.
>  The problem is, next (or N+2) GNOME, KDE and X.org itself will depend on
> systemd, and, maybe, X.org will be discontinued at all for Wayland
> (or-what-is-name-of-this-technology), which will be even more
> Linux-centric.
>
>  It is topic for other thread, but this chasing Linux in system features
> (hal/udev/systemd/whatever) needed for desktop environment is painful, and
> FreeBSD without decent modern DE will fail to attract new users :(
>
> --
> // Black Lion AKA Lev Serebryakov 
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



The convoluted hierarchy of Linux makes it a pain when working on software
porting between Linux and any BSD system. There is more similarities
between the BSD setup than between various Linux distributions.
Take, for example, sound. It is a layer that has kernel access in FreeBSD.
Even OSS has kernel level modules.
In Linux there is sound, and alsa, and pulse, and bits of esound to make
the system work. A bit of difference, eh?


Look also at the implementation of NFS on Linux. They would have saved a
lot of time doing an exact porting to Linux but that was ignored. NFSv3 is
more common than NFSv4 because the latter in Linux is still in the
developmental and porting stage.

--Actually, it is easier to see the similarities between the NFS
implementations and see the exact similarities than working with comparing
sound between the systems.--

It is Linux chasing to be on an equal plane and it is the wrong way to do
things. Recently CLang and GCC developers decided to forego the silliness
proposed by Stallman and work together. A bad analogy no less but, it is
still relevant. Why would anyone want to lock a system into a single piece
or set of software unless they did not want development to continue in
other areas.

I, like other enthusiasts, prefer a system that is simple, stable, to the
point, and easily configured.
If one wants to use the idea as an alternative then by all means do so;
but, do not make it a requirement, keep it as an option for those who want
it.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Linux chasing (Was: libinit idea)

[Lev Serebryakov]

Hello, Freddie.
You wrote 23 февраля 2014 г., 22:31:48:

FC> The main developer for systemd is very anti-portability and anti-!Linux. He
FC> had actively rejected patches that made his projects work on non-Linux
FC> systems. In order to port systemd to a non-Linux system, he wants you to
FC> first implement every Linux feature that systemd uses.
FC> systemd is a non-starter, and not with considering.
 The problem is, next (or N+2) GNOME, KDE and X.org itself will depend on
systemd, and, maybe, X.org will be discontinued at all for Wayland
(or-what-is-name-of-this-technology), which will be even more Linux-centric.

 It is topic for other thread, but this chasing Linux in system features
(hal/udev/systemd/whatever) needed for desktop environment is painful, and
FreeBSD without decent modern DE will fail to attract new users :(

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: libinit idea

[dteske]

> -Original Message-
> From: David Chisnall [mailto:thera...@freebsd.org]
> Sent: Sunday, February 23, 2014 10:18 AM
> To: Allan Jude
> Cc: FreeBSD Current
> Subject: Re: libinit idea
> 
> On 23 Feb 2014, at 18:11, Allan Jude  wrote:
> 
> > sysrc solves this nicely, it is in base now, and is great for
> > programmatically adding, removing and changing lines in rc.conf style
> > files. It is also in ports for older versions of FreeBSD where it is
> > not in base.
> 
> The problem is, there is no such thing as an rc.conf style file.  rc.conf
is just a
> shell script.  If you only edit it with sysrc, or you are careful to
preserve the
> structure, then it's fine.

Actually, sysrc is well aware that rc.conf is a shell script and sysrc will
actually
make certain that structure is preserved (regardless of whether you've
placed
shell code in rc.conf or not).

> There is absolutely nothing stopping you, however,
> from writing arbitrarily complex shell scripts inside rc.conf.  Sure, it's
a terrible
> idea to do so, but when has that ever stopped anyone?
> 

When sysrc is told to make a change, it first finds where it needs to make
that
change (/etc/rc.conf or /etc/rc.conf.local or one of other paths mentioned
in
rc_conf_files setting), it will refuse to edit the file *IF* the file
doesn't first
(before editing) pass a shell syntax check (using "sh -n FILE"). After
making the
changes in a temporarily file (produced with mktemp(1)), it again performs
yet
another syntax check (also using "sh -n FILE") to make sure that it
continues to
yield clean syntax.

On top of that, it makes certain not to muck with dynamic assignments. So it
will leave-alone an assignment such as "foo=$( bar )" if told to edit the
variable
foo -- instead opting to add a foo=newvalue after the dynamic assignment
(logic
is simple... sysrc wasn't responsible for putting that dynamic assignment
in, so
it is going to leave it as-is and put the new [static] assignment further
below.

So Allan was absolutely correct in stating that sysrc is for editing
"rc.conf style"
files -- shell scripts really. In essence, sysrc is actually a shell script
modifying
utility that takes extreme special care to rely on the fact that rc.conf
*is* a
shell script.

> An rc-replacement could enforce this by only accepting purely declarative
files
> for configuration, guaranteeing that if they were syntactically valid they
would
> also be machine editable, no matter what the user does to them.
> 

sysrc does this for you.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Darren Pilgrim]

On 2/23/2014 10:31 AM, Freddie Cash wrote:

The main developer for systemd is very anti-portability and anti-!Linux. He
had actively rejected patches that made his projects work on non-Linux
systems. In order to port systemd to a non-Linux system, he wants you to
first implement every Linux feature that systemd uses.

systemd is a non-starter, and not with considering.


It's pretty clear Lennart Poettering failed history.

Perhaps the best examples of why systemd is an anti-pattern is this: 
systemd stores logs in a binary journal.  After the Linux zealots have 
spent about two decades using binary system data storage as one of the 
reasons Windows sucks, that strikes me as particularly ironic.


The RC system we have is proof you do not need anything more than bourne 
and a respectable amount of intelligence to design a good init system.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[OutBackDingo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 02/23/2014 02:09 PM, Nikolai Lifanov wrote:
> On 2014-02-23 13:47, David Chisnall wrote:
>> On 23 Feb 2014, at 18:31, Freddie Cash 
>> wrote:
>> 
>>> The main developer for systemd is very anti-portability and 
>>> anti-!Linux. He had actively rejected patches that made his
>>> projects work on non-Linux systems. In order to port systemd to
>>> a non-Linux system, he wants you to first implement every Linux
>>> feature that systemd uses.
>>> 
>>> systemd is a non-starter, and not with considering.
>> 
>> I don't think that's a relevant discussion.  The license would
>> likely preclude systemd from making it into the base system
>> anyway.  Please let's not be too negative about the author of
>> systemd: he's responsible for more people switching from Linux to
>> FreeBSD than any other single individual I can think of and I
>> would strongly encourage him to continue.
>> 
> 
> I also noticed this.
> 
>> The relevant question is whether it does anything in a way that
>> is sufficiently sensible to merit a FreeBSD service management 
>> infrastructure doing it in the same (or a similar) way.
>> 
>> Oh, two things missing from my original list:
>> 
>> - Service jails should be able to run without an init process,
>> with just the required libraries installed and the host machine's
>> init system starting the jail and the service process(es) inside
>> it.
>> 
> 
> Isn't this a bit too complicated? If there is an init script under 
> $jail/usr/local/etc/rc.d, then the host init will need to find it,
> which can be even more complicated if rc search path in the jail is
> customized (prefixed if it's managed by a different department, for
> example). Host init will have to read the jail configuration, parse
> it too, and then manage children and pids of the jailed services,
> including reparenting, all within a jail context. Then the admin in
> that jail would need to be able to restart services, affecting host
> init, which opens a whole new can of worms. If init program is
> skinny and not too complicated, which it is, there is no tangible
> overhead. And if a jail really needs a single simple service, init
> process in the jail can *be* that, like jexec myjail /bin/sh -c
> somestuff (or even /usr/local/bin/myservice -c myservice conf).
> 
>> - The init system should use process descriptors, not pids, for 
>> tracking processes, preventing issues with pid reuse and so on
>> (and removing the need to write pid files).  If process
>> descriptors do not provide the required functionality (e.g. the
>> ability to trace forked children) then this should be added.
>> 
> 
> This is a good idea.
> 
>> David

openrc already does this and runs on FreeBSD, ive been using it on 5
boxes in testing so far, clealy replaces init without breaking rc.conf
configurations.

>> 
>> ___ 
>> freebsd-current@freebsd.org mailing list 
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current To
>> unsubscribe, send any mail to 
>> "freebsd-current-unsubscr...@freebsd.org"
> ___ 
> freebsd-current@freebsd.org mailing list 
> http://lists.freebsd.org/mailman/listinfo/freebsd-current To
> unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJTCkyWAAoJEP7cFACJNhNalmgH/1hquNUT75g4xOGc8CX+RyVD
kVYKW2SUgMOCCQwgXMydsZUafQ8kLSU24H8T9W2J/q2WDm1lWedqeO9/yk7t3pNS
8+c8YsTIuAYtPgiBES65YW667Cj9+FwN268fEqF58/WNS6kNx8snCfoRkvy6l7jN
M62ajdNJtgSxF/Iwyfuq4W6REBW3CF4rL+g64OGrK8PQ6yPteJfM3CUGQoUlHXZC
KHHY+qMYBSb/H0j9z7PzcpJsC/bb4fJRzccfVc34IV0ovdevLtQeJojTy4E55NhB
kWTX1EDRYVxv9Zvy1uPut5qAtc0b+UB5sAPON0RGxBB0rzjzIYZXlieKo4s752w=
=BXYO
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Nikolai Lifanov]

On 2014-02-23 13:47, David Chisnall wrote:

On 23 Feb 2014, at 18:31, Freddie Cash  wrote:

The main developer for systemd is very anti-portability and 
anti-!Linux. He

had actively rejected patches that made his projects work on non-Linux
systems. In order to port systemd to a non-Linux system, he wants you 
to

first implement every Linux feature that systemd uses.

systemd is a non-starter, and not with considering.


I don't think that's a relevant discussion.  The license would likely
preclude systemd from making it into the base system anyway.  Please
let's not be too negative about the author of systemd: he's
responsible for more people switching from Linux to FreeBSD than any
other single individual I can think of and I would strongly encourage
him to continue.



I also noticed this.


The relevant question is whether it does anything in a way that is
sufficiently sensible to merit a FreeBSD service management
infrastructure doing it in the same (or a similar) way.

Oh, two things missing from my original list:

- Service jails should be able to run without an init process, with
just the required libraries installed and the host machine's init
system starting the jail and the service process(es) inside it.



Isn't this a bit too complicated? If there is an init script under 
$jail/usr/local/etc/rc.d, then the host init will need to find it, which 
can be even more complicated if rc search path in the jail is customized 
(prefixed if it's managed by a different department, for example). Host 
init will have to read the jail configuration, parse it too, and then 
manage children and pids of the jailed services, including reparenting, 
all within a jail context. Then the admin in that jail would need to be 
able to restart services, affecting host init, which opens a whole new 
can of worms. If init program is skinny and not too complicated, which 
it is, there is no tangible overhead. And if a jail really needs a 
single simple service, init process in the jail can *be* that, like 
jexec myjail /bin/sh -c somestuff (or even /usr/local/bin/myservice -c 
myservice conf).



- The init system should use process descriptors, not pids, for
tracking processes, preventing issues with pid reuse and so on (and
removing the need to write pid files).  If process descriptors do not
provide the required functionality (e.g. the ability to trace forked
children) then this should be added.



This is a good idea.


David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[David Chisnall]

On 23 Feb 2014, at 18:31, Freddie Cash  wrote:

> The main developer for systemd is very anti-portability and anti-!Linux. He
> had actively rejected patches that made his projects work on non-Linux
> systems. In order to port systemd to a non-Linux system, he wants you to
> first implement every Linux feature that systemd uses.
> 
> systemd is a non-starter, and not with considering.

I don't think that's a relevant discussion.  The license would likely preclude 
systemd from making it into the base system anyway.  Please let's not be too 
negative about the author of systemd: he's responsible for more people 
switching from Linux to FreeBSD than any other single individual I can think of 
and I would strongly encourage him to continue.

The relevant question is whether it does anything in a way that is sufficiently 
sensible to merit a FreeBSD service management infrastructure doing it in the 
same (or a similar) way.

Oh, two things missing from my original list:

- Service jails should be able to run without an init process, with just the 
required libraries installed and the host machine's init system starting the 
jail and the service process(es) inside it.

- The init system should use process descriptors, not pids, for tracking 
processes, preventing issues with pid reuse and so on (and removing the need to 
write pid files).  If process descriptors do not provide the required 
functionality (e.g. the ability to trace forked children) then this should be 
added.

David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Nikolai Lifanov]

On 2014-02-23 13:17, David Chisnall wrote:

On 23 Feb 2014, at 18:11, Allan Jude  wrote:


sysrc solves this nicely, it is in base now, and is great for
programmatically adding, removing and changing lines in rc.conf style
files. It is also in ports for older versions of FreeBSD where it is 
not

in base.


The problem is, there is no such thing as an rc.conf style file.
rc.conf is just a shell script.  If you only edit it with sysrc, or
you are careful to preserve the structure, then it's fine.  There is
absolutely nothing stopping you, however, from writing arbitrarily
complex shell scripts inside rc.conf.  Sure, it's a terrible idea to
do so, but when has that ever stopped anyone?

An rc-replacement could enforce this by only accepting purely
declarative files for configuration, guaranteeing that if they were
syntactically valid they would also be machine editable, no matter
what the user does to them.

David



Just my $0.02:

I don't believe our current RC is broken. It's faster than most, it 
supports an early-late divider, virtual targets (NETWORK, etc.), 
dependencies, etc.
Rewriting scripts (units) in C has a non-trivial cost to customization 
for end users. I have custom, packaged, RC scripts in /usr/local that 
are pretty easy to add and maintain. Shell script logic can go there and 
not in rc.conf proper. The rcorder program provides a pretty good idea 
for when these can be run, and, as already pointed out, sysrc can be 
used to add/remove/configure these on clusters of (automatically) 
managed machines. If all scripts a properly written, "service foo 
status" can also provide something that can be acted upon by 
configuration management systems.
Serialization is great (libnv), but it's just gravy. The only feature I 
see that's missing is (SMF-style) service management, but for hardware 
events, like losing a network link or a disk, can be plugged in to devd 
configuration, also easily. Also, in real-life deployments, shutting 
down service dependencies is not practical either. For example, if 
postfix crashes, I don't want to stop postgey or dovecot. I just want to 
nanny postfix back up rather than trying to bring up the whole stack. 
Also, forking a shell does not have any significant cost to it when 
bringing up something like MySQL, since it's a small fraction of where 
the system spends its time to bring up a useful service.


Rewriting scripts in C doesn't provide service management or give any 
on-demand (inetd, read: launchd) functionality.


- Nikolai Lifanov

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Freddie Cash]

Typos and terseness brought to you by the LG G2 running SlimKat.
On Feb 23, 2014 10:22 AM, "Lucius Rizzo"  wrote:
>
> * Andreas Nilsson  [2014-02-23 09:33]:
> > Imho, the replacement to init and rc-scripts I sometimes think about
> > would be to import SMF from opensolaris/illumos. There one can at
> > least get the commands run and config used without looking at the
> > source code.
>
> I like SMF from Solaris 11 onwards and even SmartOS. However, I have
> found to like systemd and use via systemctl on Arch far nicer than any
> other rc scripts to date.
>
> Anyone care to share their thoughts on the pros and cons of something
> like systemd the way Arch does?

The main developer for systemd is very anti-portability and anti-!Linux. He
had actively rejected patches that made his projects work on non-Linux
systems. In order to port systemd to a non-Linux system, he wants you to
first implement every Linux feature that systemd uses.

systemd is a non-starter, and not with considering.

In theory, devd could be extended to support socket-activation, and the
support for that added to RCng, providing the bulk of the systemd features,
without having to deal with the systemd devs.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Lucius Rizzo]

* Andreas Nilsson  [2014-02-23 09:33]:
> Imho, the replacement to init and rc-scripts I sometimes think about
> would be to import SMF from opensolaris/illumos. There one can at
> least get the commands run and config used without looking at the
> source code.

I like SMF from Solaris 11 onwards and even SmartOS. However, I have
found to like systemd and use via systemctl on Arch far nicer than any
other rc scripts to date. 

Anyone care to share their thoughts on the pros and cons of something
like systemd the way Arch does?

-- 

| _o_ |_)o_ _  _  
|_|_|(_||_|_> | \|/_/_(_) - Lucius.Tel
--
++ Q:   How many Bell Labs Vice Presidents does it take to change a light bulb? 
++
++ A:   That's proprietary information.  Answer available from AT&T on payment 
++
++  of license fee (binary only). ++
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[David Chisnall]

On 23 Feb 2014, at 18:11, Allan Jude  wrote:

> sysrc solves this nicely, it is in base now, and is great for
> programmatically adding, removing and changing lines in rc.conf style
> files. It is also in ports for older versions of FreeBSD where it is not
> in base.

The problem is, there is no such thing as an rc.conf style file.  rc.conf is 
just a shell script.  If you only edit it with sysrc, or you are careful to 
preserve the structure, then it's fine.  There is absolutely nothing stopping 
you, however, from writing arbitrarily complex shell scripts inside rc.conf.  
Sure, it's a terrible idea to do so, but when has that ever stopped anyone?

An rc-replacement could enforce this by only accepting purely declarative files 
for configuration, guaranteeing that if they were syntactically valid they 
would also be machine editable, no matter what the user does to them.

David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Allan Jude]

On 2014-02-23 04:12, David Chisnall wrote:
> Hi Bruno,
> 
> 3) It's easy for tools to add lines to rc.conf, it's hard to remove them.  If 
> you're administering a large number of nodes, you want to be able to push out 
> updates to all, in a way that doesn't clobber local changes.  Text file 
> processing here is always going to be a fragile hack.
> 

sysrc solves this nicely, it is in base now, and is great for
programmatically adding, removing and changing lines in rc.conf style
files. It is also in ports for older versions of FreeBSD where it is not
in base.

At ScaleEngine, we make extensive use of a global rc.conf pushed by
puppet, with local modifications in rc.conf.local (and we actually
extend this with an rc.conf.role file, added to the rc_conf_files.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: libinit idea

[David Chisnall]

Hi Bruno,

To preface this, I'd like to say that I do believe that FreeBSD does need a 
more modern init system.  SMF on Solaris and Launchd on Darwin both have some 
advantages.  These are what I see as the limitations in our current design (not 
in priority order):

1) Options are implicit.  Because init scripts are written in a Turing-complete 
language, including routines scattered across a large number of files, it's 
very difficult for a tool (e.g. a GUI system administration tool like the SMF 
GUI on Solaris) to enumerate all of the options.  Additionally, these options 
are untyped so a GUI that does manage to find them can't tell whether it should 
be displaying a checkbox (for a boolean value) or a text field.  Additionally, 
it can't tell what the dependencies are between them.

2) Dependency information between services is poor.  If service A depends on B, 
and B is not running, then starting A should start B.  If nothing else depends 
on B and B was not explicitly started, then B should stop.  The last part is 
the hard one with shell scripts, because it requires maintaining the dependency 
graph and effectively garbage collecting it (explicitly started services are 
roots, dependencies are references).

3) It's easy for tools to add lines to rc.conf, it's hard to remove them.  If 
you're administering a large number of nodes, you want to be able to push out 
updates to all, in a way that doesn't clobber local changes.  Text file 
processing here is always going to be a fragile hack.

4) Shell scripts are a good tool for invoking complex sequences of command-line 
programs, but have a measurable overhead relative to fork() / exec() for 
running a single command.  Most rc actions just run a single program, we should 
only be doing a shell invocation for ones that are more complex.

5) In a world where we're moving towards sandboxing services via Capsicum, the 
service launcher needs to be able to create services with a potentially large 
set of initial file descriptors (including a socket to Casper), based on the 
configuration policy.

6) As with launchd, it would make sense for a service management framework to 
subsume inetd and cron (and devd!) functionality, because timer events, network 
events, system startup, system shutdown, device attachment, and explicit 
service starting from the command line are even sources that trigger changes to 
the service dependency graph.

7) Inspecting the system status is very hard with the current system.  I want 
to be able to see a list of all running services, along with the reason why 
they were started.

8) Again, in capsicum world we'd like inetd-like functionality for UNIX domain 
sockets, so that it's possible to lazily start things like powerboxes.

In terms of design, I don't think that turning rc scripts into libraries is a 
win.  I would like to see them replaced by a declarative config file in a 
structured format that provides dependency information, configuration options, 
and the commands required to start / stop the service (which can be shell 
scripts, but don't have to invoke a shell).  The configuration options should 
be separate from the configuration variables, with the former provided by the 
package and the latter by the system administrator.

We already have, in the base system, a library for parsing a structured 
configuration file format that is used for the pkg tools and a library with an 
efficient binary serialisation (libnv) that is used for various 
Capsicum-related functions.  I'd like to see these combined so that in embedded 
devices all of the configuration files could be stored in the binary 
serialisation (which is denser and faster to parse) and turned back into the 
human-readable one only for editing.  

I do like the idea of an init library, so that the functionality is easily 
reusable and can be run in nested scopes.  I don't think we gain anything by 
rewriting shell scripts in C, other than a maintenance headache and a 
requirement that all port maintainers be fluent C programmers...

David


On 22 Feb 2014, at 23:54, Bruno Lauzé  wrote:

> https://github.com/brunolauze/libnit
> 
> I know there's really big debate about init system but here's my tentative to 
> propose a new model to replace rc.
> 
> Let's call it libinit but the name as no significance for now.
> 
> I started coding a library with the following architecture.
> 
> the main idea is to rewrite rc in C language.
> 
> a utility called system would act a little bit like service command does.
> 
> a folder would contains libraries instead of scripts inside [target]/etc/rc.d
> so we can add as many librairies a user desire and interlink the order of 
> each piece among all like in rc.
> 
> each library would follow and expose the following pattern:
> 
> char **provide(); /* returns all the PROVIDE a library contains */
> 
> then for each provide() value the library would expose :
> 
> XXX_provide()
> XXX_require()
> XXX_before()
> XXX_keywords()
> 

Re: libinit idea

[Andreas Nilsson]

On Sun, Feb 23, 2014 at 8:46 AM, Scot Hetzel  wrote:

> On Sat, Feb 22, 2014 at 5:54 PM, Bruno Lauzé  wrote:
> > https://github.com/brunolauze/libnit
> >
> > I know there's really big debate about init system but here's my
> tentative to propose a new model to replace rc.
> >
> > Let's call it libinit but the name as no significance for now.
> >
> > I started coding a library with the following architecture.
> >
> > the main idea is to rewrite rc in C language.
>

To me this seems like much work for no real gain. And it would make it that
much harder to debug a misbehaving "script", in more than one way:
* c is a lot longer than sh, ie sh expresses the logic that much more
clearly.
* to actually see the new "script" would require to have the source code
installed, something far from everybody has.

> >
> > a utility called system would act a little bit like service command does.
> >
> > a folder would contains libraries instead of scripts inside
> [target]/etc/rc.d
> > so we can add as many librairies a user desire and interlink the order
> of each piece among all like in rc.
> >
> libraries don't belong in [target]/etc/rc.d, they would have to be in
> {/usr,}/lib{exec,}/rc.d or ${PREFIX}/lib{exec,}/rc.d
>
> Imho, the replacement to init and rc-scripts I sometimes think about would
be to import SMF from opensolaris/illumos. There one can at least get the
commands run and config used without looking at the source code.

Best regards
Andreas
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libinit idea

[Scot Hetzel]

On Sat, Feb 22, 2014 at 5:54 PM, Bruno Lauzé  wrote:
> https://github.com/brunolauze/libnit
>
> I know there's really big debate about init system but here's my tentative to 
> propose a new model to replace rc.
>
> Let's call it libinit but the name as no significance for now.
>
> I started coding a library with the following architecture.
>
> the main idea is to rewrite rc in C language.
>
> a utility called system would act a little bit like service command does.
>
> a folder would contains libraries instead of scripts inside [target]/etc/rc.d
> so we can add as many librairies a user desire and interlink the order of 
> each piece among all like in rc.
>
libraries don't belong in [target]/etc/rc.d, they would have to be in
{/usr,}/lib{exec,}/rc.d or ${PREFIX}/lib{exec,}/rc.d


-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

libinit idea

[Bruno Lauzé]

https://github.com/brunolauze/libnit

I know there's really big debate about init system but here's my tentative to 
propose a new model to replace rc.

Let's call it libinit but the name as no significance for now.

I started coding a library with the following architecture.

the main idea is to rewrite rc in C language.

a utility called system would act a little bit like service command does.

a folder would contains libraries instead of scripts inside [target]/etc/rc.d
so we can add as many librairies a user desire and interlink the order of each 
piece among all like in rc.

each library would follow and expose the following pattern:

char **provide(); /* returns all the PROVIDE a library contains */

then for each provide() value the library would expose :

XXX_provide()
XXX_require()
XXX_before()
XXX_keywords()

and optionally:
XXX_canstart();
XXX_prestart();
XXX_start();
XXX_status();
XXX_stop();

and also:

XXX_mycommand(int argc, char **argv);

essentially repeating the rc.subr  model

system utilty would source /etc/defaults/rc.conf, then source result of 
rc_conf_files loaded

On init, /sbin/init would call /sbin/system init instead of running script 
/etc/rc

on init, system would scan folder (let's suppose /lib/init.d and 
/usr/local/init.d for now)
try dlopen() each *.so* files
and grab provide(); xxx_provide(), xxx_require(), xxx_before() and 
xxx_keyword() for each one.
compile a list of "service" discovered and do an "rcorder".

The benefits is to avoid firing so many utility to manage to init the system.

Replicating all small helper function from rc to C language like load_kld would 
avoid opening a process and do real syscall at moment.
Heavily use pthread, waitpid, etc...

So instead of firing /sbin/devfs /dev rule -s 1 applyset 
call direcly what's would run inside devfs -> rule_main in 
src/sbin/devfs/rule.c ...
cut the fat

here's an example to show /etc/rc.d/abi conversion to abi.c

abi.h:
#ifndef __ABI_H__
#define __ABI_H__
#include "../default.h"

#define PROVIDE         abi
#define REQUIRE         { "archdep" }
#define KEYWORD         { NOJAIL }

#include "../common.h"

#endif


abi.c:
#include "abi.h"

int sysvipc_start()
{
        if (load_kld("sysvmsg"))
                if (load_kld("sysvsem"))
                        return load_kld("sysvshm");
        return -1;
}

int linux_start()
{
        return load_kld("linux");
}

int srv4_start()
{
        if (load_kld("svr4elf") == 0)
                return load_kld("svr4");
        return (-1);
}

#define __canstart
int abi_canstart()
{
        return is_enabled("sysvipc") || is_enabled("linux") || 
is_enabled("srv4");
}

int abi_start()
{
        int err1 = 0, err2 = 0, err3 = 0;
        if (is_enabled("sysvipc")) err1 = sysvipc_start();
        if (is_enabled("linux")) err2 = linux_start();
        if (is_enabled("srv4")) err3 = srv4_start();
        return err1 && err2 && err3;
}

#include "../common.c"


where common.h and common.c implement everything by default a little bit like 
rc.subr does.
e.g: PID_FILE and COMMAND macros implement the start by itself, etc...


as you can see really similar to what we have in the script file...

Then the system utility would also allow digging into the libraries with 
command like:
system accounting rotatelog
etc..

I uploaded a quick start to show some code and expose more the idea.

https://github.com/brunolauze/libinit



Thanks in advance for your comments.  
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"