Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Nicolas Charles
    @ncharles
    Thank you for the files. It seems that it simply stop to reports at 00:07. Just to be sure I understand correctly, do the next run restores the status, or is it still missing ?
    Status is persisted for 1440 minutes - which is maybe too little on a non 5 minutes schedule
    pmg
    @pmg7557_twitter
    @ncharles status, or is it still missing? Now status is Ok for Node Philippe3 but Missing for Node Di.
    Status is persisted for 1440 minutes - which is maybe too little on a non 5 minutes schedule - probably. Can we change easily this 'parameter', it should probably be 1440 + 'run period'? or fixe at 1440 + 6x60
    Nicolas Charles
    @ncharles
    ok, so on node philippe it is run one day out of two, and di it was not run on the 4th and the 6th
    pmg
    @pmg7557_twitter
    @ncharles Yes
    Nicolas Charles
    @ncharles
    Can you check if the touched file was touched today on node "di" ? so that we can identify if it wasn't run at all or simply a reporting error?
    pmg
    @pmg7557_twitter
    @ncharles checked : nothing, the script did not run.
    Nicolas Charles
    @ncharles
    ok, thank you
    these are useful information
    Nicolas Charles
    @ncharles
    @pmg7557_twitter Would you be willing to do a test ? There are 2 jobs in the same directive, could you split it in 2 directives? I'm unsure as to why it would have an impact, but we never know
    pmg
    @pmg7557_twitter
    @ncharles Done. I have also reduce the period of node 'di' to 1h/59mn random
    Nicolas Charles
    @ncharles
    Thank you
    pmg
    @pmg7557_twitter
    @ncharles Hello Nicolas, this morning the pb is still present, on 1 node for job1 and 4 for job2. I'll check the logs.
    pmg
    @pmg7557_twitter

    @ncharles For node "di", the pb is on job2, and I saw with the logs (see below) is not yet lauched, that's not abnormal with an opening time 0-23

    grep jobScheduler /var/rudder/cfengine-community/outputs/* | grep launched | grep sauve_bd2 | cut -d' ' -f 1
    /var/rudder/cfengine-community/outputs/cf_n_di1601513420_Thu_Oct1_02_50_20_2020_0x7f79e7f33700:2020-10-01T00:50:33+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di1601599788_Fri_Oct2_02_49_48_2020_0x7f79e7f33700:2020-10-02T00:50:03+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di1601686219_Sat_Oct3_02_50_19_2020_0x7f79e7f33700:2020-10-03T00:51:06+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di1601859016_Mon_Oct5_02_50_16_2020_0x7f79e7f33700:2020-10-05T00:50:29+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di1602031770_Wed_Oct7_02_49_30_2020_0x7f2e1b284700:2020-10-07T00:49:45+00:00

    grep jobScheduler /var/rudder/cfengine-community/outputs/* | grep launched | grep tmp_check | cut -d' ' -f 1
    /var/rudder/cfengine-community/outputs/cf_n_di1601455764_Wed_Sep_30_10_49_24_2020_0x7f79e7f33700:2020-09-30T08:49:38+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di
    1601542187_Thu_Oct1_10_49_47_2020_0x7f79e7f33700:2020-10-01T08:50:02+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di
    1601628620_Fri_Oct2_10_50_20_2020_0x7f79e7f33700:2020-10-02T08:50:35+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di
    1601714990_Sat_Oct3_10_49_50_2020_0x7f79e7f33700:2020-10-03T08:50:04+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di
    1601801419_Sun_Oct4_10_50_19_2020_0x7f79e7f33700:2020-10-04T08:50:34+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di
    1601887783_Mon_Oct5_10_49_43_2020_0x7f79e7f33700:2020-10-05T08:49:58+00:00
    /var/rudder/cfengine-community/outputs/cf_n_di
    1601974175_Tue_Oct__6_10_49_35_2020_0x7f2e1b284700:2020-10-06T08:49:49+00:00

    pmg
    @pmg7557_twitter

    @ncharles The info for node with both status missing are strange, as you can see below in the logs, job1 (openning 1-6h) did not run this night and job2 just ran (8h55) but status, even now, is still missing!

    grep jobScheduler /var/rudder/cfengine-community/outputs/* | grep launched | grep sauve_bd2 | cut -d' ' -f 1
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr1601513710_Thu_Oct1_02_55_10_2020_0x7f77ec46c700:2020-10-01T00:55:14+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr1601600129_Fri_Oct2_02_55_29_2020_0x7f77ec46c700:2020-10-02T00:55:33+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr1601686552_Sat_Oct3_02_55_52_2020_0x7f77ec46c700:2020-10-03T00:55:56+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr1601772912_Sun_Oct4_02_55_12_2020_0x7f77ec46c700:2020-10-04T00:55:15+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr1601859332_Mon_Oct5_02_55_32_2020_0x7f77ec46c700:2020-10-05T00:55:35+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr1601945750_Tue_Oct6_02_55_50_2020_0x7f77ec46c700:2020-10-06T00:56:56+00:00

    grep jobScheduler /var/rudder/cfengine-community/outputs/* | grep launched | grep tmp_check | cut -d' ' -f 1
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr1601448957_Wed_Sep_30_08_55_57_2020_0x7f77ec46c700:2020-09-30T06:56:01+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr
    1601535315_Thu_Oct1_08_55_15_2020_0x7f77ec46c700:2020-10-01T06:55:18+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr
    1601621735_Fri_Oct2_08_55_35_2020_0x7f77ec46c700:2020-10-02T06:55:38+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr
    1601708157_Sat_Oct3_08_55_57_2020_0x7f77ec46c700:2020-10-03T06:56:00+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr
    1601794517_Sun_Oct4_08_55_17_2020_0x7f77ec46c700:2020-10-04T06:56:04+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr
    1601880936_Mon_Oct5_08_55_36_2020_0x7f77ec46c700:2020-10-05T06:55:39+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr
    1601967356_Tue_Oct6_08_55_56_2020_0x7f77ec46c700:2020-10-06T06:55:59+00:00
    /var/rudder/cfengine-community/outputs/cf_mail_vpn1_fr
    1602053717_Wed_Oct__7_08_55_17_2020_0x7f77ec46c700:2020-10-07T06:55:23+00:00
    /var/rudder/cfengine-community/outputs/previous:2020-10-07T06:55:23+00:00

    For node "Philipp3' (end of 1/2, both are ok)

    grep jobScheduler /var/rudder/cfengine-community/outputs/* | grep launched | grep sauve_bd2 | cut -d' ' -f 1
    /var/rudder/cfengine-community/outputs/cf_philippe31601590052_Fri_Oct2_00_07_32_2020_0x7f786a056700:2020-10-01T22:09:21+00:00
    /var/rudder/cfengine-community/outputs/cf_philippe31601762852_Sun_Oct4_00_07_32_2020_0x7f786a056700:2020-10-03T22:08:02+00:00
    /var/rudder/cfengine-community/outputs/cf_philippe31601935626_Tue_Oct6_00_07_06_2020_0x7f786a056700:2020-10-05T22:07:38+00:00
    /var/rudder/cfengine-community/outputs/cf_philippe31602022038_Wed_Oct7_00_07_18_2020_0x7f20cced5700:2020-10-06T22:07:46+00:00

    grep jobScheduler /var/rudder/cfengine-community/outputs/* | grep launched | grep tmp_check | cut -d' ' -f 1
    /var/rudder/cfengine-community/outputs/cf_philippe31601590052_Fri_Oct2_00_07_32_2020_0x7f786a056700:2020-10-01T22:09:21+00:00
    /var/rudder/cfengine-community/outputs/cf_philippe31601762852_Sun_Oct4_00_07_32_2020_0x7f786a056700:2020-10-03T22:08:02+00:00
    /var/rudder/cfengine-community/outputs/cf_philippe31601935626_Tue_Oct6_00_07_06_2020_0x7f786a056700:2020-10-05T22:07:38+00:00
    /var/rudder/cfengine-community/outputs/cf_philippe31602022038_Wed_Oct7_00_07_18_2020_0x7f20cced5700:2020-10-06T22:07:47+00:00

    pmg
    @pmg7557_twitter
    @ncharles With these logs I can imagine that there are two or three different pbs, persistence of the status info, launch of the jobs and ?. Let me know if you want me to do more tests.
    pmg
    @pmg7557_twitter
    @ncharles I created job2 (tmp_check) for these tests, it does not consume ressources I'll change the opening time from 0-23 to 0-2, it should be easier to analyse the pbs.
    Nicolas Charles
    @ncharles
    Thank you
    vpn1 doesn't answer yet, because last run at 8:55 executed the command, so report will be at next run: 9:55
    Nicolas Charles
    @ncharles
    it should be ok now
    pmg
    @pmg7557_twitter
    @ncharles Yes, ok for job2 as you wrote; but of course still KO for job1 (not ran this night)
    @ncharles For your information when I updated teh bug 1803, I set severity to major as I don't know how to solve it inside rudder, but it's not a big pb as it's easy to scedule the job outside rudder (cron, ...)
    Nicolas Charles
    @ncharles
    perfect
    Alex
    @alex17865_twitter
    Hi guys, I have this problem too: https://issues.rudder.io/issues/18257
    Do you know if a solution exist ?
    Nicolas Charles
    @ncharles
    Hi @alex17865_twitter - we don't have a solution yet, but the workaround is described in the issue - it should help you workaround it
    Alex
    @alex17865_twitter
    I have a better workaround I think. Go in <Rudder_Dir>, and do "git add techniques/* && git commit -a" in ssh.
    But it's a little bit annoying to do this each time ><
    Francois Armand
    @fanf
    @alex17865_twitter what Rudder version? (to update the ticket if still present in 6.1)
    Suvi
    @Suvi8

    Hallo, i have a problem updating the OS with yum update:

    it gives me this error:

    yum update
    Loaded plugins: fastestmirror
    Setting up Update Process
    Determining fastest mirrors
    epel/metalink | 29 kB 00:00

    • base: mirror.init7.net
    • epel: pkg.adfinis-sygroup.ch
    • extras: mirror.init7.net
    • updates: mirror.init7.net
      Rudder_6.0 | 2.9 kB 00:00
      Rudder_6.0/primary_db | 5.7 kB 00:00
      https://download.rudder.io/rpm/6.1/RHEL_6/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 401 Unauthorized"
      Trying other mirror.
      Error: Cannot retrieve repository metadata (repomd.xml) for repository: Rudder_6.1. Please verify its path and try again
    Its a CentOS 6.10
    Alexis Mousset
    @amousset
    Hi @Suvi8, CentOS 6 requires usingthe private repositories as it is not publicly supported anymore, but only as part of the subscription.
    Alex
    @alex17865_twitter
    @fanf last one on debian 10
    Alexis Mousset
    @amousset
    https://docs.rudder.io/reference/6.1/installation/agent/rhel.html#_installation in the blue info box :
    echo '[Rudder_6.1]
    name=Rudder 6.1
    baseurl=https://LOGIN:PASSWORD@download.rudder.io/rpm/6.1/RHEL_$releasever/
    gpgcheck=1
    gpgkey=https://LOGIN:PASSWORD@download.rudder.io/rpm/rudder_rpm_key.pub' > /etc/yum.repos.d/rudder.repo
    Suvi
    @Suvi8
    @amousset yes, we have a rudder subscription
    Alexis Mousset
    @amousset
    (and replace LOGIN/PASSWORD by your technical account's credentials)
    Suvi
    @Suvi8

    @amousset its already there, when i want to clean the yum cache it shows:

    yum clean all
    Loaded plugins: fastestmirror
    Repository Rudder_6.1 is listed more than once in the configuration

    Alexis Mousset
    @amousset
    Oh indeed I did not read the first message correctly!
    Suvi
    @Suvi8
    yesi can access the repo with username/password in my browser
    Francois Armand
    @fanf
    @alex17865_twitter just to be sure: last 6.1 or 6.0 (sorry to ask, it's to be able to reproduce in your condition, else we won't know for sure if we corrected the pb)
    Alex
    @alex17865_twitter
    @fanf 6.1 :)
    Francois Armand
    @fanf
    @alex17865_twitter thanks, ticket updated accordingly
    _ChezW@m_
    @JrmChP_twitter
    Hey, is there an easy way to change a node uuid post re install, or do i have to delete it from rudder, and accept again ?
    Francois Armand
    @fanf
    @JrmChP_twitter depends of your use case. If you reinstalled rudder agent on the same node, and want a different uuid, you can use rudder agent reinit which will reset everything, create a new uuid, and send an inventory. Still, you will have to delete the old node/uuid and accepte the new one.
    _ChezW@m_
    @JrmChP_twitter
    ok thanks. no way to change the uuid on rudder after an os reinstall for example ?
    Francois Armand
    @fanf
    @JrmChP_twitter I don't know what you want to achieve. If it's an OS reinstall, it is a different node, no? Likely, not the same rules/groupes/etc. What would you like to keep from the other node/uuid ?
    _ChezW@m_
    @JrmChP_twitter
    @fanf juste a reinstall of same os / config on a host that was used for test before production. I was lazy and want to avoid declaration of properties :-)
    Francois Armand
    @fanf
    @JrmChP_twitter perhaps you could have used the old uuid, but there is some subtlilies regarding agent keys restoration, not sure it's documented
    _ChezW@m_
    @JrmChP_twitter
    ok thanks @fanf . I finally juste remove and accept nodes again. Only 3 manual properties to apply. by the way, maybe full copying a property from one node to another may be a cool improvements on future release :-)