Hi,
I''ve just changed my debian preseed configuration to install the debian
unstable package of puppet v0.22.1. As part of the preseed I have a late
command that clobbers the /etc/init.d/puppet file into using the puppet
standalone program and not the puppetd (as this is what I''m using).
Since
the upgrade to 0.22.1 every boot hangs during the initd. Going into
standalone mode and executing the same command works fine, i.e. puppet -v
--use-nodes /srv/puppet/manifests/site.pp and NOT /etc/init.d/puppet start.
Any ideas why puppet is hanging at this stage in the new version as it
worked in v0.20 using the same init.d file and site.pp or where can I find
out what''s going on?
Here''s the clobbered init.d file (to prove that there''s
nothing funny going
on here):
#! /bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
PROGS=/usr/bin/puppet
PROGS_OPTS="-v --use-nodes /srv/puppet/manifests/site.pp"
NAME=puppet
DESC="puppet (standalone) configuration management tool"
test -x $PROGS || exit 0
[ -r /etc/default/puppet ] && . /etc/default/puppet
. /lib/lsb/init-functions
start_puppet() {
export RUBYLIB=/srv/puppet
eval $PROGS $PROGS_OPTS
}
case "$1" in
start)
log_begin_msg "Running $DESC"
start_puppet
log_end_msg 0
;;
stop)
;;
restart|force-reload)
log_begin_msg "Re-running $DESC"
stop_puppet
sleep 1
start_puppet
log_end_msg 0
;;
*)
echo "Usage: $0 {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
Regards,
Andrew
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
matthew.malthouse@guardian.co.uk
2007-Mar-15 18:04 UTC
Unmanageable state ''maintenance'' on Sol10 service
Hi, Puppet knows enabled and disabled but seems upset by ''maintenance'' for a svc service. Mar 15 17:36:17 nynewhost puppetd[551]: [ID 702911 daemon.error] (//default/common/common_services/common_service_firewall/Service[firewall]) Failed to retrieve current state: Unmanageable state ''maintenance'' on service /network/ipfilt At least if I disbale (twice) the servive, or repair it, puppet stops complaining. Is this Puppet lack or do I need to tell Puppet something? -- Matthew ------------------------------------------------------------------ Visit Guardian Unlimited - the UK''s most popular newspaper website http://guardian.co.uk http://observer.co.uk ------------------------------------------------------------------ The Newspaper Marketing Agency Opening Up Newspapers http://www.nmauk.co.uk ------------------------------------------------------------------ This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News & Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396 _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Mar 15, 2007, at 11:04 AM, matthew.malthouse@guardian.co.uk wrote:> > Hi, > > Puppet knows enabled and disabled but seems upset by ''maintenance'' > for a svc service. > > Mar 15 17:36:17 nynewhost puppetd[551]: [ID 702911 daemon.error] (// > default/common/common_services/common_service_firewall/Service > [firewall]) Failed to retrieve current state: Unmanageable state > ''maintenance'' on service /network/ipfilt > > At least if I disbale (twice) the servive, or repair it, puppet > stops complaining. > > Is this Puppet lack or do I need to tell Puppet something?What would you prefer Puppet to do in this condition? I think it''s correct that it''s an unmanageable state, although maybe it should just be a warning instead of an error. Without knowing how to correct the maintenance condition, all Puppet can do is skip past the service, right? -- Don''t tell me how hard you work. Tell me how much you get done. -- James Ling --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
matthew.malthouse@guardian.co.uk
2007-Mar-15 18:25 UTC
Re: Unmanageable state ''maintenance'' on Sol10 service
> > Puppet knows enabled and disabled but seems upset by ''maintenance'' > > for a svc service. > > > > Mar 15 17:36:17 nynewhost puppetd[551]: [ID 702911 daemon.error] (// > > default/common/common_services/common_service_firewall/Service > > [firewall]) Failed to retrieve current state: Unmanageable state > > ''maintenance'' on service /network/ipfilt > > > > At least if I disbale (twice) the servive, or repair it, puppet > > stops complaining. > > > > Is this Puppet lack or do I need to tell Puppet something? > > What would you prefer Puppet to do in this condition? > > I think it''s correct that it''s an unmanageable state, although maybe > it should just be a warning instead of an error. Without knowing how > to correct the maintenance condition, all Puppet can do is skip past > the service, right?I was assuming that since Puppet issued a daemon.error message that _it_ was suffering in some fashion because of this. If not then warn might indeed be more apropriate. -- Matthew ------------------------------------------------------------------ Visit Guardian Unlimited - the UK''s most popular newspaper website http://guardian.co.uk http://observer.co.uk ------------------------------------------------------------------ The Newspaper Marketing Agency Opening Up Newspapers http://www.nmauk.co.uk ------------------------------------------------------------------ This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News & Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396 _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 15 Mar 2007, at 18:16, Luke Kanies wrote:> What would you prefer Puppet to do in this condition? > > I think it''s correct that it''s an unmanageable state, although maybe > it should just be a warning instead of an error. Without knowing how > to correct the maintenance condition, all Puppet can do is skip past > the service, right?My 2p: once things get into this state on Solaris a hard restart (disable, disable again, enable) attempt is worthwhile, because the last puppet run might have fixed the problem that caused the maintenance state in the first place. If things don’t work out, Solaris will put it back into maintenance before the next puppetd run. However my smf experience is limited and there may be a better strategy. Gary Law gary.law@gmail.com _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Mar 15, 2007, at 11:25 AM, matthew.malthouse@guardian.co.uk wrote:> > I was assuming that since Puppet issued a daemon.error message that > _it_ was suffering in some fashion because of this. If not then > warn might indeed be more apropriate.Ah, I see. If I do anything other than throw an error here, then Puppet will try to take action in some way, which is probably not what you want. I could possibly find another way of conveying that the service is in an unmanageable state, but I think this is sufficiently informative and it doesn''t cause any actual problems. -- Sabbagh''s Second Law: The biggest problem with communication is the illusion that it has occurred. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Charlie Schluting
2007-Mar-18 21:53 UTC
Re: Unmanageable state ''maintenance'' on Sol10 service
On 3/15/07, Luke Kanies <luke@madstop.com> wrote:> On Mar 15, 2007, at 11:25 AM, matthew.malthouse@guardian.co.uk wrote: > > > > I was assuming that since Puppet issued a daemon.error message that > > _it_ was suffering in some fashion because of this. If not then > > warn might indeed be more apropriate. > > Ah, I see. > > If I do anything other than throw an error here, then Puppet will try > to take action in some way, which is probably not what you want. > > I could possibly find another way of conveying that the service is in > an unmanageable state, but I think this is sufficiently informative > and it doesn''t cause any actual problems.I, too, believe it''d be very nice for puppet to just run ''svcadm clear $FMRI'' in this case. Like someone else said, if the service is really broken, SMF will just put it back in maint mode. Often times, the service is fixed and just needs to be cleared of the maintenance state. I''ve been in the same situation a few times, and I had to ssh to each box to fix it. -Charlie
On Mar 18, 2007, at 4:53 PM, Charlie Schluting wrote:> > I, too, believe it''d be very nice for puppet to just run ''svcadm clear > $FMRI'' in this case. Like someone else said, if the service is really > broken, SMF will just put it back in maint mode. > > Often times, the service is fixed and just needs to be cleared of the > maintenance state. I''ve been in the same situation a few times, and I > had to ssh to each box to fix it.I''m perfectly willing to do this, I just figured it was dangerous or something. Anyone disagree with doing this? -- Like frozen sentries of the serengeti, the century-old termite mounds had withstood all tests of time and foe - all tests, that is, except the one involving drunken aardvarks and a stolen wrecking ball." -- Gary Larson --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Mar 14, 2007, at 8:35 PM, Andrew Leach wrote:> Hi, > > I''ve just changed my debian preseed configuration to install the > debian unstable package of puppet v0.22.1. As part of the preseed I > have a late command that clobbers the /etc/init.d/puppet file into > using the puppet standalone program and not the puppetd (as this is > what I''m using). Since the upgrade to 0.22.1 every boot hangs > during the initd. Going into standalone mode and executing the same > command works fine, i.e. puppet -v --use-nodes /srv/puppet/ > manifests/site.pp and NOT /etc/init.d/puppet start. Any ideas why > puppet is hanging at this stage in the new version as it worked in > v0.20 using the same init.d file and site.pp or where can I find > out what''s going on?I have no idea what''s going on here, but I''d definitely like to get this fixed. Is it all machines, or just one? -- If you would be a real seeker after truth, it is necessary that at least once in your life you doubt, as far as possible, all things. -- Rene Descartes --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hi, Currently, I have only one machine which is a test bed. I''m creating a fully automated install. I''ve tried changing the preseed configuration such that it installs the older version of ruby (as some of the documementation suggusts that there is a problem with the debian packages) but that doesn''t work either. I''ve also tried with puppet v0.22.2 and that still hangs. I''ll send you my files directly so that you can have a look at them. Thanks, Andrew On 21/03/07, Luke Kanies <luke@madstop.com> wrote:> > On Mar 14, 2007, at 8:35 PM, Andrew Leach wrote: > > > Hi, > > > > I''ve just changed my debian preseed configuration to install the > > debian unstable package of puppet v0.22.1. As part of the preseed I > > have a late command that clobbers the /etc/init.d/puppet file into > > using the puppet standalone program and not the puppetd (as this is > > what I''m using). Since the upgrade to 0.22.1 every boot hangs > > during the initd. Going into standalone mode and executing the same > > command works fine, i.e. puppet -v --use-nodes /srv/puppet/ > > manifests/site.pp and NOT /etc/init.d/puppet start. Any ideas why > > puppet is hanging at this stage in the new version as it worked in > > v0.20 using the same init.d file and site.pp or where can I find > > out what''s going on? > > I have no idea what''s going on here, but I''d definitely like to get > this fixed. > > Is it all machines, or just one? > > -- > If you would be a real seeker after truth, it is necessary that at > least once in your life you doubt, as far as possible, all things. > -- Rene Descartes > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Matthew Flanagan
2007-Mar-23 01:06 UTC
Re: Unmanageable state ''maintenance'' on Sol10 service
On 3/21/07, Luke Kanies <luke@madstop.com> wrote:> On Mar 18, 2007, at 4:53 PM, Charlie Schluting wrote: > > > > I, too, believe it''d be very nice for puppet to just run ''svcadm clear > > $FMRI'' in this case. Like someone else said, if the service is really > > broken, SMF will just put it back in maint mode. > > > > Often times, the service is fixed and just needs to be cleared of the > > maintenance state. I''ve been in the same situation a few times, and I > > had to ssh to each box to fix it. > > I''m perfectly willing to do this, I just figured it was dangerous or > something. > > Anyone disagree with doing this?I think it is safe to do this.> > -- > Like frozen sentries of the serengeti, the century-old termite mounds > had withstood all tests of time and foe - all tests, that is, except > the one involving drunken aardvarks and a stolen wrecking ball." > -- Gary Larson > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >-- matthew http://wadofstuff.blogspot.com
On Mar 22, 2007, at 8:06 PM, Matthew Flanagan wrote:> On 3/21/07, Luke Kanies <luke@madstop.com> wrote: >> On Mar 18, 2007, at 4:53 PM, Charlie Schluting wrote: >>> >>> I, too, believe it''d be very nice for puppet to just run ''svcadm >>> clear >>> $FMRI'' in this case. Like someone else said, if the service is >>> really >>> broken, SMF will just put it back in maint mode. >>> >>> Often times, the service is fixed and just needs to be cleared of >>> the >>> maintenance state. I''ve been in the same situation a few times, >>> and I >>> had to ssh to each box to fix it. >> >> I''m perfectly willing to do this, I just figured it was dangerous or >> something. >> >> Anyone disagree with doing this? > > I think it is safe to do this.Is someone willing to file this as an enhancement request, with the specific command to use to clear the service? How many times should this be tried (i.e., I expect I''ll have to clear, reparse the output, and check again)? Or should I just try once and assume the service successfully clears? -- You only have to be open minded if you''re wrong. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Matthew Flanagan
2007-Apr-05 00:42 UTC
Re: Unmanageable state ''maintenance'' on Sol10 service
On 4/3/07, Luke Kanies <luke@madstop.com> wrote:> On Mar 22, 2007, at 8:06 PM, Matthew Flanagan wrote: > > > On 3/21/07, Luke Kanies <luke@madstop.com> wrote: > >> On Mar 18, 2007, at 4:53 PM, Charlie Schluting wrote: > >>> > >>> I, too, believe it''d be very nice for puppet to just run ''svcadm > >>> clear > >>> $FMRI'' in this case. Like someone else said, if the service is > >>> really > >>> broken, SMF will just put it back in maint mode. > >>> > >>> Often times, the service is fixed and just needs to be cleared of > >>> the > >>> maintenance state. I''ve been in the same situation a few times, > >>> and I > >>> had to ssh to each box to fix it. > >> > >> I''m perfectly willing to do this, I just figured it was dangerous or > >> something. > >> > >> Anyone disagree with doing this? > > > > I think it is safe to do this. > > Is someone willing to file this as an enhancement request, with the > specific command to use to clear the service? How many times should > this be tried (i.e., I expect I''ll have to clear, reparse the output, > and check again)? Or should I just try once and assume the service > successfully clears?I would only try and clear it once. SMF''s svc.startd(1M) handles retrying and only puts a service into maintenance state if: "three method failures happen in a row, or if the service is restarting more than once a second"> > -- > You only have to be open minded if you''re wrong. > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >-- matthew http://wadofstuff.blogspot.com
Charlie Schluting
2007-Apr-05 01:46 UTC
Re: Unmanageable state ''maintenance'' on Sol10 service
On 4/4/07, Matthew Flanagan <mattimustang@gmail.com> wrote:> > I would only try and clear it once. SMF''s svc.startd(1M) handles > retrying and only puts a service into maintenance state if: > > "three method failures happen in a row, or if the service is > restarting more than once a second" >Well that depends on the service manifest. But yeah, once is good. Filed as an enhancement, finally. I''ve been away for a while :) -Charlie