Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
When (and if) Gentoo will switch to systemd?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 16, 17, 18  Next  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
mayak
n00b
n00b


Joined: 16 Jul 2013
Posts: 26

PostPosted: Thu Feb 20, 2014 8:49 pm    Post subject: Reply with quote

While doing some further reading I came across the following article:
http://lwn.net/Articles/576078/

The article is quite old - probably not new to you guys.

On the other hand I have some late-breaking news from systemd:
http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html
https://plus.google.com/+TomGundersen/posts/bDQCP5ZyQ3h
https://plus.google.com/+TomGundersen/posts/JhaBNn8Ytwu
https://plus.google.com/+TomGundersen/posts/anS8GseSAfw
https://plus.google.com/+TomGundersen/posts/8d1tzMJWppJ
https://plus.google.com/+TomGundersen/posts/U6Es8bpmMbP
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Thu Feb 20, 2014 9:24 pm    Post subject: Reply with quote

Thanks for the links, I await the even larger train wreck, LoL

Next up iptables integration into systemd (and you thought I was full of um...fertilizer when I mentioned it earlier. :lol:
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
mayak
n00b
n00b


Joined: 16 Jul 2013
Posts: 26

PostPosted: Thu Feb 20, 2014 9:58 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Thanks for the links, I await the even larger train wreck, LoL


Actually I am not sure if this is going to be a "train wreck".
It's just a different direction the GNU userland (or maybe RH userland?) is taking.

Windows and Apple are also not following the "Unix Philosophy" and are working ~well~.

I see many people supporting systemd for better consistency between the different Linux distributions.
Now with many distributions agreeing on one init system - why don't they just agree on one package manager?
This is an honest question - I don't mean to provoke in any way!

One package manager = bigger community, more testing, more features, better code(?)

Personally I do like the old principles a lot but I also try to understand the new concepts/directions GNU/Linux is taking.

Meanwhile I am trying to get into FreeBSD* so I can compare the two systems once the new Linux OS is out.

*
http://vimeo.com/85594954
http://www.bsdnow.tv/
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Thu Feb 20, 2014 10:09 pm    Post subject: Reply with quote

mayak wrote:
I see many people supporting systemd for better consistency between the different Linux distributions.
Now with many distributions agreeing on one init system - why don't they just agree on one package manager?
This is an honest question - I don't mean to provoke in any way!

One package manager = bigger community, more testing, more features, better code(?)


I don't take your question as provocation.
If I wanted that kind of environment, I would use windows or apple.
I like the choices provided by unix (all variants).

I don't wish to take away anyone elses choice of having a windows style unix system.
More power to them.
But on the other hand I don't wish them to limit my ability to choose differently.

I left windows for a reason and if the choice is between a half-baked windows clone ala RH, or windows
then windows has much more maturity to its credit. Why would I want RH?????
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
mayak
n00b
n00b


Joined: 16 Jul 2013
Posts: 26

PostPosted: Thu Feb 20, 2014 10:41 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I don't take your question as provocation.

Thank you. I really mean to understand the reasons/motives behind the "one-(GNU)Linux-userland".

Anon-E-moose wrote:
I left windows for a reason and if the choice is between a half-baked windows clone ala RH, or windows
then windows has much more maturity to its credit. Why would I want RH?????


Very true and the same applies to me.
I was creating many MSI packages a few years ago.
This gave me a chance to "look under the engine hood" of Windows which in return made me switch to Linux completely.

Believe it or not I was just recently attending a Microsoft Premier Workshop (although I am a Linux Sysadmin ^^).
In case Red Hat is trying to go the same route I wish them luck - because the available Microsoft System Operation Consoles are very powerful tools in their domain.

If at all possible, I personally prefer the KISS principles...
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w

PostPosted: Fri Feb 21, 2014 2:47 am    Post subject: Reply with quote

my big question is when is eselect /sbin/init coming down the line? systemd / sysv / runit / s6 / daemontools / busybox use differing inits. i see it this summer, as they are posting things in google sumer of code 2014 that include runit integration and it would be the 1st step to the community starting to accept openrc as a choice instead of ramming it down our throats. s6 was a hair too crazy for me to deal with but theres a bunch of systemd slamming going on there.

alas, if s6 worked out of the box its slamming might appear to have some validity.


Last edited by 666threesixes666 on Fri Feb 21, 2014 8:04 am; edited 1 time in total
Back to top
View user's profile Send private message
gotyaoi
Tux's lil' helper
Tux's lil' helper


Joined: 01 Apr 2013
Posts: 137

PostPosted: Fri Feb 21, 2014 7:54 am    Post subject: Reply with quote

steveL wrote:
That's great gotyaoi, motivated users are essential for QA. Could you take a look at what Anon-E-moose pointed out, if you can? I've never used monit, runit or s6; about the only thing I've used in this vein is xinetd many years ago. So it would be good to have info from people who have, and have some idea of exactly what they want to accomplish with it in a networked environment. ie what kind of checks, events to react to, and presumably any service can be run via "socket activation" or xinetd-functionality.
Anon-E-moose wrote:
Ran across this when reading something else https://github.com/qnikst/openrc/compare/s-vision

It's a patch about adding monit to openrc.

Excellent :) qnikst's work is what I was thinking of wrt keeping the old cgroup interface (with delete_on_release); I recall him saying that it was easy enough to do, but he didn't think the new setup as modified for systemd, would be as nice to work with. So I'd consider his work as "source we need to save" before the big switch to a crippled kernel impl, and something we need to keep working.

Not sure about starting monit directly from inittab, but I guess it would only be another process in the same place, perhaps with more awareness of openrc.


Haven't been able to actually set this up yet, but here's what I gathered from just research. I only looked at monit and s6, as examples of polling and signalling respectively, but other's could do as well.

Basically, for supervising from within init, no matter what it is, the general refrain was put it in the inittab as something like SV:2345:respawn:/program/executable. They all need some mechanism to ensure they're running almost no matter what, and that seems to be what we have available in sysvinit.

For s6, advantages seem to be that it's very lightweight. It can be setup to do no polling at all, in which case I assume we would signal changes to it through openrc scripts. It accepts both pure signals and has a cli as well. There are a couple cooperating parts that make it up, and a bunch of programs that it essentially tries to copy from daemontools, but it seems pretty solid, if slightly limited. Not that limited is a bad thing. It has a... (slightly odd?) logging method, which it would probably be good to take advantage of. According to it's documentation, it has a hard limit of 500 processes to monitor.

I've used monit at work, a little bit. It's got a lot of options in terms of configurability. A lot. It's heavier than s6, and uses polling to check services, but again, configurability. It has some features that might not be used, like file, directory, filesystem and network connection monitoring, shell script testing and system resource tests, but it also has some potentially nice features, like email alerts and a built in web interface (which can be disabled). Interfacing it with openrc (which it looks like qnikst already has going), is dropping files in an included directory and telling monit to reread it's conf.

They both have pros and cons. We could probably have multiple options for process monitoring even beyond these two, as long as we could get a consistent interface going. I'll give the monit version a shot this weekend and see what I can get going with s6 as well.

Not quite sure what you mean with regards to networking/xinetd, could you elaborate?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Feb 21, 2014 4:24 pm    Post subject: Reply with quote

gotyaoi wrote:
Haven't been able to actually set this up yet, but here's what I gathered from just research. I only looked at monit and s6, as examples of polling and signalling respectively, but other's could do as well.

Basically, for supervising from within init, no matter what it is, the general refrain was put it in the inittab as something like SV:2345:respawn:/program/executable. They all need some mechanism to ensure they're running almost no matter what, and that seems to be what we have available in sysvinit.

Oh, I'm fine with that (it's how openrc starts), all I'd like is to customise it, so that we're starting openrc, which forks off rc-update, and then execs the monitor. That pid can then be restarted by init, with a standard mechanism (rundir) to know it's crashed. This is more because we'd like to add a bit more functionality to that process, or one it handles, eg for cgroups and dbus events. But if you think how it is now is fine (ie respawn the monitor from inittab directly, and keep openrc separate) and qnikst's happy, I'm happy :) I just recall discussing having an integrated process with him, ie an openrc process that hangs around. Just not pid1, ofc.

Quote:
They both have pros and cons. We could probably have multiple options for process monitoring even beyond these two, as long as we could get a consistent interface going.

Yeah, qnikst is doing the modular thing, so hopefully that will be an option (drop-in whichever one you want, or leave it with none) and switching to try stuff out will be fun :)
Quote:
I'll give the monit version a shot this weekend and see what I can get going with s6 as well.

Nice one. I'll see if I can raise qnikst on IRC, if he's not too caught up in real-life.
Quote:
Not quite sure what you mean with regards to networking/xinetd, could you elaborate?

Well, firstly we'll need people to test who admin at least a small network (even if at home) that has some sorts of real-life scenarios, eg to do with network interfaces going up and down, and services perhaps being suspended til they come back (off the top of my head: as I said I'm not an admin.) Xinetd just refers to the socket activation thing, since inetd was the first to run services in that vein, albeit for on-demand starting of services, rather than having the socket available before the service, which is implicit in the former.

Don't recall all the details of how it works (though fd inheritance is an old technique, and more "modern" fd-passing has been around since the late 80s: it was written up in 1990, and standardised that decade) but istr tcp-wrappers as part of the background.
Back to top
View user's profile Send private message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Fri Feb 21, 2014 5:43 pm    Post subject: Reply with quote

666threesixes666 wrote:
my big question is when is eselect /sbin/init coming down the line?

Well, there is the systemd-love overlay, courtesy of lxnay (Sabayon Linux lead developer and, as far as I know, still a Gentoo developer):

Code:
# eselect init list
Available init implementations:
  [1]   systemd *
  [2]   sysvinit
# eselect init set 2
Setting the init implementation to sysvinit
# eselect init list
Available init implementations:
  [1]   systemd
  [2]   sysvinit *
# eselect init set 1
Setting the init implementation to systemd
# eselect init list
Available init implementations:
  [1]   systemd *
  [2]   sysvinit
#

I use OpenRC myself, but apparently you could install it in Gentoo if you wanted.

Gentoo Bug No. 468898 - (systemd-love) [Tracker] systemd-love systemd enhancements
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
keet
Guru
Guru


Joined: 09 Sep 2008
Posts: 565

PostPosted: Sun Mar 02, 2014 6:41 pm    Post subject: Reply with quote

I just switched to systemd on a few Gentoo computers, I didn't really have many problems. On one of them, I had tried systemd a year or two ago, and I had many services in /etc/systemd/system, so I needed to delete those to avoid several 'failed' messages. I had trouble making iptables work, but finally figured it out. I still haven't fixed the encrypted swap problem, though I tried the steps in a forum post, the bug report, and the systemd instructions, but it's not a major problem because I can just comment the line in fstab and enable it manually after it boots.
Back to top
View user's profile Send private message
gotyaoi
Tux's lil' helper
Tux's lil' helper


Joined: 01 Apr 2013
Posts: 137

PostPosted: Tue Mar 04, 2014 6:57 am    Post subject: Reply with quote

Ok, so over the weekend might have been a slightly ambitious plan :)

Anyway, I've got it working, after a fashion. The repo as it is doesn't work quite right, there's a few typos and such, so here's what I had to change to get it working.

to install
  1. install monit
  2. add 'INCLUDE /run/openrc-monit/files/*' to /etc/monitrc !!!NOTE: not INCLUDE /run/openrc-monit/* like the comment in rc-supervise-monit.sh says!!!
  3. add to inittab 'mo:2345:respawn:/usr/bin/monit -Ic /etc/monitrc' !!!NOTE: if installing monit from portage, not /usr/local/bin/monit like the comment in rc-supervise-monit.sh says!!!
  4. make a local overlay, copy 9999 openrc ebuild and files directory to it
  5. edit ebuild and change EGIT_REPO_URI to use qnikst instead of OpenRC, and add EGIT_BRANCH="s-vision"
  6. unmask and install
to patch
  1. in /lib/rc/sh/runscript.sh, change 'if [ -z "${RC_SUPERVISE_MODULE:-$rc_supervise_module}" ] ; then' to 'if [ -n "${RC_SUPERVISE_MODULE:-$rc_supervise_module}" ] ; then', reversing the test.
  2. in /lib/rc/sh/rc-supervise-monit.sh, remove the extraneous 'fi;' at the end of the plugin_monit_start_post function.
  3. in /lib/rc/sh/rc-supervise-monit.sh, there's a case block for start and stop, which should be replaced with two functions, 'supervision_start' and 'supervision_stop'. See sh/rc-supervise-monit.sh.in in the source repo for how it should look.
  4. in /lib/rc/sh/rc-supervise-monit.sh, insert '[ -d /run/openrc-monit/files/ ] || mkdir -p /run/openrc-monit/files' right after the file case in plugin_monit_start_post. Again see sh/rc-supervise-monit.sh.in in the source repo.
  5. in /lib/rc/sh/rc-supervise-monit.sh, replace the instance of RC_SVCNANE with RC_SVCNAME
  6. in /lib/rc/sh/rc-supervise-monit.sh, add 'sleep 1' after 'monit reload' in plugin_monit_start_post. This may be a design flaw.
  7. in /lib/rc/sh/rc-supervise-monit.sh, change plugin_monit_post_stop to plugin_monit_stop_pre.
  8. in /lib/rc/sh/rc-supervise-monit.sh, change 'rm /run/openrc-monit/${RC_SVCNAME}' to 'rm /run/openrc-monit/files/${RC_SVCNAME}'
  9. change 'monit start ${RC_SVCNAME}' and 'monit stop ${RC_SVCNAME}' to 'monit monitor ${RC_SVCNAME}' and 'monit unmonitor ${RC_SVCNAME}' respectively. This may be a design flaw.
Then you need to add
Code:
rc_supervise_module="monit"
rc_monit_type="file"

to /etc/conf.d/${RC_SVCNAME} and provide a monit fragment in /run/openrc-monit/files/${RC_SVCNAME} for every service you want monitored. At the moment, I'm having a little trouble with the monit fragment, as it requires commands for starting and stopping the service, and we can't very well use runscript, now can we? I'm thinking something using start-stop-daemon directly, but I'm not sure. The restart would have to somehow be invisible to openrc, and considering I'm not to familiar with how openrc determines if something is running or not, I'm not sure how to proceed.

In the places where I say it might be a design flaw, There might be some improvements on how the plugin could work with monit, but I'm reserving thinking about that until I can get it to restart a service.

Also, if anyone could tell me what start_postss and stop_postss are all about in rc-supervise-monit.sh, that would be cool 'cause I have no clue.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Mar 05, 2014 2:01 am    Post subject: Reply with quote

Great work, gotyaoi :-)

I'd suggest you login to IRC:chat.freenode.net, channel #openrc and talk with qnikst when he's around (haven't been able to raise him, pinged him about this thread.) You can certainly patch in your git repo and submit a bug with a git diff against his branch.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Mar 05, 2014 2:08 am    Post subject: Reply with quote

Quote:
The restart would have to somehow be invisible to openrc, and considering I'm not to familiar with how openrc determines if something is running or not, I'm not sure how to proceed.


From limited problems with a daemon or two dieing when playing with things I think it looks for a pid (file) rather than checking for a running pid.

It's told me that a process was running even when it wasn't (I checked with ps) so I assume what I said above is true
ie telling some init.d process to start it responds with "already started" (paraphrased)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
gotyaoi
Tux's lil' helper
Tux's lil' helper


Joined: 01 Apr 2013
Posts: 137

PostPosted: Wed Mar 05, 2014 4:49 am    Post subject: Reply with quote

@steveL Ok, I sent a pull request with the changes I made. I'll see if I can get on IRC at one point as well.

@Anon-E-moose Yeah, I've had a issue a time or two where it thought something was running even though it was very dead. The first thing I did at that point though was delete the PID file, and it still thought it was alive. I had to tell runscript to zap it to reset the state to stopped, so I think it might be doing something more complicated.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Mar 05, 2014 5:17 am    Post subject: Reply with quote

gotyaoi wrote:
Then you need to add
Code:
rc_supervise_module="monit"
rc_monit_type="file"

to /etc/conf.d/${RC_SVCNAME} and provide a monit fragment in /run/openrc-monit/files/${RC_SVCNAME} for every service you want monitored. At the moment, I'm having a little trouble with the monit fragment, as it requires commands for starting and stopping the service, and we can't very well use runscript, now can we? I'm thinking something using start-stop-daemon directly, but I'm not sure. The restart would have to somehow be invisible to openrc, and considering I'm not to familiar with how openrc determines if something is running or not, I'm not sure how to proceed.

Why can't monit just call /etc/init.d/script start etc? It's not in the same process as openrc or one of its scripts, is it, or does it monitor the pid it launches?

The wider point of pids, is that really you don't want pidfiles at all (see Q3.2), but to start the daemon in foreground mode, and wait for it as a child ("monitor the pid" above.)
Back to top
View user's profile Send private message
qnikst
n00b
n00b


Joined: 05 Mar 2014
Posts: 3

PostPosted: Wed Mar 05, 2014 6:49 am    Post subject: Reply with quote

@gotyaoi Thanks for the fixes, seems that I've fixed them on my system but haven't committed them. I've pulled request and will check

gotyaoi wrote:

]change 'monit start ${RC_SVCNAME}' and 'monit stop ${RC_SVCNAME}' to 'monit monitor ${RC_SVCNAME}' and 'monit unmonitor ${RC_SVCNAME}' respectively. This may be a design flaw.

[/list]


On my system I have following file:

Code:

# cat /etc/conf.d/monit-files/nginx
check process nginx
   with pidfile "/run/nginx.pid"
   start program = "/etc/init.d/nginx zap ; /etc/init.d/nginx start"
   stop  program = "/sbin/rc-service nginx stop"
   if 2 restart within 3 cycles then timeout
   if totalmem > 100 Mb then alert
   depends on nginx.conf

check file nginx.conf
   with path /etc/nginx/nginx.conf
   if changed checksum
      then exec "/sbin/rc-service nginx reload"


On start openrc copies that file to /run/openrc-monit/files/${RC_SVCNAME} and so monit can handle it. Then it's possible to start nginx as usual via s-s-d, so it was a main idea.

gotyaoi wrote:
Also, if anyone could tell me what start_postss and stop_postss are all about in rc-supervise-monit.sh, that would be cool 'cause I have no clue.


this is a main problem and concern about this patches. Main idea is to be able to plug additional actions inside a runscript.sh, and because we don't know how much actions do we
have I introduced a string start_posts variable with a list of functions that should be called instead of start_post, so any plugin can add them.
Back to top
View user's profile Send private message
gotyaoi
Tux's lil' helper
Tux's lil' helper


Joined: 01 Apr 2013
Posts: 137

PostPosted: Wed Mar 05, 2014 7:02 am    Post subject: Reply with quote

qnikst wrote:
gotyaoi wrote:
Also, if anyone could tell me what start_postss and stop_postss are all about in rc-supervise-monit.sh, that would be cool 'cause I have no clue.


this is a main problem and concern about this patches. Main idea is to be able to plug additional actions inside a runscript.sh, and because we don't know how much actions do we
have I introduced a string start_posts variable with a list of functions that should be called instead of start_post, so any plugin can add them.


Ok, but I'm just not sure why some of them seem to have an extra 's' on the end of the variable name, like:

start_posts=${start_postss}${start_postss+':'}plugin_monit_start_post;

vs:

stop_pres=${stop_postss}${stop_posts+':'}plugin_monit_stop_pre;

also, the use of stop_posts and stop_postss when assigning to the variable stop_pres was confusing.

Wasn't sure if it was a typo or not, so I didn't change it.

Regarding using '/etc/init.d/nginx start' as part of the start command, my only worry is that this might call plugin_monit_start_post() again, either redundantly or in a way that might mess things up.
Back to top
View user's profile Send private message
qnikst
n00b
n00b


Joined: 05 Mar 2014
Posts: 3

PostPosted: Wed Mar 05, 2014 8:31 am    Post subject: Reply with quote

gotyaoi wrote:
qnikst wrote:
gotyaoi wrote:
Also, if anyone could tell me what start_postss and stop_postss are all about in rc-supervise-monit.sh, that would be cool 'cause I have no clue.


this is a main problem and concern about this patches. Main idea is to be able to plug additional actions inside a runscript.sh, and because we don't know how much actions do we
have I introduced a string start_posts variable with a list of functions that should be called instead of start_post, so any plugin can add them.


Ok, but I'm just not sure why some of them seem to have an extra 's' on the end of the variable name, like:

start_posts=${start_postss}${start_postss+':'}plugin_monit_start_post;

vs:

stop_pres=${stop_postss}${stop_posts+':'}plugin_monit_stop_pre;


is a bug, should be with one s everywhere.

gotyaoi wrote:

also, the use of stop_posts and stop_postss when assigning to the variable stop_pres was confusing.

Wasn't sure if it was a typo or not, so I didn't change it.


it's also a bug, I'll fix it ASAP.

gotyaoi wrote:

Regarding using '/etc/init.d/nginx start' as part of the start command, my only worry is that this might call plugin_monit_start_post() again, either redundantly or in a way that might mess things up.


Yes, there are at least 2 ways to handle this situation: 1. track extra environment variable 2. track existance of service file, i.e. if there is a service file in /run/openrc-monit/* then monit is notified, and we may run normal s-s-d, and then monit monitor (afaiu calling monit monitor twice will make no harm).
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w

PostPosted: Wed Mar 05, 2014 8:49 am    Post subject: Reply with quote

https://wiki.gentoo.org/wiki/Monit

i banged on the wiki a bit before you guys started investigating monit. i like monit because it doesn't require a potentially dangerous init swapping, and has an easy to use web interface.
Back to top
View user's profile Send private message
qnikst
n00b
n00b


Joined: 05 Mar 2014
Posts: 3

PostPosted: Wed Mar 05, 2014 10:11 am    Post subject: Reply with quote

666threesixes666 wrote:
https://wiki.gentoo.org/wiki/Monit

i banged on the wiki a bit before you guys started investigating monit. i like monit because it doesn't require a potentially dangerous init swapping, and has an easy to use web interface.


I can't agree with using monit as a service, because it's not got supervised itself, and it may fail in different cases.
Also current script allows both init swapping and existing configuration it this case just monit monitor, monit unmonitor is called in runscript.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Mar 05, 2014 10:56 am    Post subject: Reply with quote

gotyaoi wrote:
@Anon-E-moose Yeah, I've had a issue a time or two where it thought something was running even though it was very dead. The first thing I did at that point though was delete the PID file, and it still thought it was alive. I had to tell runscript to zap it to reset the state to stopped, so I think it might be doing something more complicated.


Now that I think about it you may be right on that. Most of the time I tell the init.d service to stop and then start.
And that worked except for one service (don't remember what it was) but it wouldn't run the stop telling me it wasn't running, but wouldn't start telling me that it was already running. I never investigated past that point.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
ArneBab
Guru
Guru


Joined: 24 Jan 2006
Posts: 429
Location: Graben-Neudorf, Germany

PostPosted: Wed Mar 05, 2014 11:43 am    Post subject: Reply with quote

mayak wrote:
Windows and Apple are also not following the "Unix Philosophy" and are working ~well~.


Windows and Apple are developed by a fixed group of developers who have clear orders what to do. They do not benefit as much from the ability to experiment as openly developed free software projects. When someone writes a better MacOSX network-setup program, either Apple makes it the default (and employs the developer) or it will rot. When someone writes a better GNU/Linux network-setup program, some people start using it and contribute ideas. If it proves to provide features no other tools offers, more people will flock to it and the developers of existing programs might start to improve their tools. And when it is ready for casual users, distributions might make it the default - until something better comes along.

As an example for this process, just look how OpenRC moved forward with the competition of systemd.

The problem is now, that systemd tries to become the default and then stop anything else from replacing it by making everything depend on itself.

Quote:
Now with many distributions agreeing on one init system - why don't they just agree on one package manager?
This is an honest question - I don't mean to provoke in any way!

One package manager = bigger community, more testing, more features, better code(?)


The problem with that approach is that you have to decide what you need.

apt-get does not fulfill my needs: I need USE-flags and simple ways to unmask packages. To really provide this, you need a source-distro (because many of the USE-flags are simply compile-flags).

But portage does not fulfill the needs of those who need package to install swiftly, who want to build small systems which do not need a compiler but which can still be updated and who want to ensure that all possible configurations work well (because in Gentoo there’s an almost unlimited number of possible configurations due to USE flags and unmasking single packages).

And then, a super package manager would have to provide all the features of each current package manager (else some people would keep using the old package manager). Since this is not easy and all package managers are continually improved (which makes replacing them coding against a moving target), you would end up with xkcd 927: https://xkcd.com/927/

PackageKit provides a nicer idea: Creating a simplified API to the package managers, so there can be a unified GUI for installing packages and updating the system.
_________________
Being unpolitical means being political without realizing it. - Arne Babenhauserheide ( http://draketo.de )

pkgcore: So fast that it feels unreal - by doing only what is needed.
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1248
Location: 42.68n 85.41w

PostPosted: Wed Mar 05, 2014 11:51 am    Post subject: Reply with quote

so make a distro that is binary that supplies binaries for all possible use cases. :D
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Wed Mar 05, 2014 2:56 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Thanks for the links, I await the even larger train wreck, LoL

Next up iptables integration into systemd (and you thought I was full of um...fertilizer when I mentioned it earlier. :lol:


http://linux.slashdot.org/story/13/10/19/2118247/nftables-to-replace-iptables-in-the-linux-kernel in case you weren't aware yet.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Mar 05, 2014 4:12 pm    Post subject: Reply with quote

666threesixes666 wrote:
so make a distro that is binary that supplies binaries for all possible use cases. :D

Funnily enough, that's what the "core distro" idea (on wilder days known as GnomeOS) is all about. systemd is part of that same idea, from the same group of developers, from what I've read.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 16, 17, 18  Next
Page 11 of 18

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum