On 06/21/2018 04:39 PM, Robie Basak wrote:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better.
>
> It looks like upstream added a PIDFile entry to the systemd service
> definition in 1.16.1, which is included in Bionic and Cosmic. So it's
> likely that this bug
Public bug reported:
After having crashed, sssd will not start, because the old PIDfile is still
present. The fact that the process does not exist any more does not cause the
PIDfile to be cleaned up.
This bug is already known, but not fixed, upstream:
https://pagure.io/SSSD/sssd/issue/3528
On 12/01/2014 10:42 PM, Stig Sandbeck Mathisen wrote:
That's a delightfully evil hack. Will using an upstart job work instead,
or do you need to keep track of the PID there, as well (something for
post-start, then)?
Matthaus Owens of Puppet Labs responded that Puppet *does* write its own
PID.
On 12/02/2014 12:21 AM, Matthaus Owens wrote:
Sorry, I should have said pidfile is written to $rundir/agent.pid.
$rundir defaults to $vardir/run if not specified in puppet.conf.
Thank you! Now my config works, and this 'bug' report should never have
existed. :)
--
You received this bug
On 12/01/2014 10:42 PM, Stig Sandbeck Mathisen wrote:
That's a delightfully evil hack. Will using an upstart job work instead,
or do you need to keep track of the PID there, as well (something for
post-start, then)?
Matthaus Owens of Puppet Labs responded that Puppet *does* write its own
PID.
On 12/02/2014 12:21 AM, Matthaus Owens wrote:
Sorry, I should have said pidfile is written to $rundir/agent.pid.
$rundir defaults to $vardir/run if not specified in puppet.conf.
Thank you! Now my config works, and this 'bug' report should never have
existed. :)
--
You received this bug
Public bug reported:
Abstract:
Puppet initscript doesn't record the correct PID. WIth this patch, it does.
Longer version:
When the Puppet agent daemon gets started, /etc/init.d/puppet records a PID in
/var/run/puppet/${NAME}.pid, but it is the wrong one. Puppet may fork half a
dozen times
Public bug reported:
Abstract:
When the Puppet agent daemon is unable to get a certificate, it dies on
receiving SIGUSR1.
Longer version:
Right after boot, the Puppet agent daemon is started. It may be running before
hostname resolution is available. If it is, Puppet is unable to receive a
Version data:
Ubuntu Trusty
Puppet 3.4.3-1 0
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to puppet in Ubuntu.
https://bugs.launchpad.net/bugs/1397898
Title:
incorrect PID in initscript
To manage notifications about this bug go to:
On 12/01/2014 06:49 PM, Robie Basak wrote:
Then isn't something else broken that causes puppet to be started before
hostname resolution is available? What is on your system that causes
hostname resolution to not be available? Can we fix that instead?
Perhaps we can. Puppet runs from a SystemV
It should go to Debian in the first instance, assuming that Debian is
Ok. Then it'll have to wait until I can confirm that Debian is affected
as well.
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to puppet in Ubuntu.
On 12/01/2014 07:31 PM, Robie Basak wrote:
What is it trying to look up? Itself, or something else? I'd expect a
self-lookup to always succeed.
It tries to look up the Puppet server, to fetch a certificate from.
Maybe it also tries to look up itself. But that would succeed, indeed.
If for some
Public bug reported:
Abstract:
Puppet initscript doesn't record the correct PID. WIth this patch, it does.
Longer version:
When the Puppet agent daemon gets started, /etc/init.d/puppet records a PID in
/var/run/puppet/${NAME}.pid, but it is the wrong one. Puppet may fork half a
dozen times
Public bug reported:
Abstract:
When the Puppet agent daemon is unable to get a certificate, it dies on
receiving SIGUSR1.
Longer version:
Right after boot, the Puppet agent daemon is started. It may be running before
hostname resolution is available. If it is, Puppet is unable to receive a
Version data:
Ubuntu Trusty
Puppet 3.4.3-1 0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1397898
Title:
incorrect PID in initscript
To manage notifications about this bug go to:
On 12/01/2014 06:49 PM, Robie Basak wrote:
Then isn't something else broken that causes puppet to be started before
hostname resolution is available? What is on your system that causes
hostname resolution to not be available? Can we fix that instead?
Perhaps we can. Puppet runs from a SystemV
It should go to Debian in the first instance, assuming that Debian is
Ok. Then it'll have to wait until I can confirm that Debian is affected
as well.
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
On 12/01/2014 07:31 PM, Robie Basak wrote:
What is it trying to look up? Itself, or something else? I'd expect a
self-lookup to always succeed.
It tries to look up the Puppet server, to fetch a certificate from.
Maybe it also tries to look up itself. But that would succeed, indeed.
If for some
Please don't bother any more. I offered the patch upstream, and it was
committed there. (Plus a line that fixes the memory leak I introduced
above.)
Regards
Jurjen
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
Hi,
Version info:
Using Ubuntu 14.04 LTS 'Trusty', and nfs-utils 1.2.8.
Symptoms:
Mounting kerberized NFS4 shares fails when the host is joined to an Active
Directory domain, but not with the conventional name. Non-kerberized mounts
succeed. Hosts joining the domain with
I opened a PR on Github as Raphaël requested.
One more thing: the Trusty source package depends neither on flex nor on
bison. I think it should, but I'm not sure enough to open another bug.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
Err.. s/depends/build-depends/
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to augeas in Ubuntu.
https://bugs.launchpad.net/bugs/1302638
Title:
augeas-tools fails to parse krb5.conf (solution provided)
To manage notifications about
I opened a PR on Github as Raphaël requested.
One more thing: the Trusty source package depends neither on flex nor on
bison. I think it should, but I'm not sure enough to open another bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Err.. s/depends/build-depends/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1302638
Title:
augeas-tools fails to parse krb5.conf (solution provided)
To manage notifications about this bug go to:
I'm the one who should do the thanking: I'm using your distro.
I have not sent the changes upstream.
I'm not very familiar with the jargon of parse tree structure. I'd say it
obviously causes changes in the structure of the tree: it adds leaves. But I
presume the question is meant: Are there
Ok, I cloned the GitHub repository, forked, making changes.
As for unit tests, it looks to me like an entire lens is the unit of testing,
so I would edit lenses/tests/test_krb5.aug to include some previously unparsed
in- and output. Is that what you want me to do?
Also, it's not unlikely that
I'm the one who should do the thanking: I'm using your distro.
I have not sent the changes upstream.
I'm not very familiar with the jargon of parse tree structure. I'd say it
obviously causes changes in the structure of the tree: it adds leaves. But I
presume the question is meant: Are there
Ok, I cloned the GitHub repository, forked, making changes.
As for unit tests, it looks to me like an entire lens is the unit of testing,
so I would edit lenses/tests/test_krb5.aug to include some previously unparsed
in- and output. Is that what you want me to do?
Also, it's not unlikely that
** Patch added: output of diff -u krb5.aug.old
/usr/share/augeas/lenses/dist/krb5.aug
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+attachment/4065670/+files/krb5.aug.patch
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Public bug reported:
In Trusty, augtool doesn't parse the default /etc/krb5.conf
There are multiple issues. The lens cannot handle some keywords, it cannot
handle heading digits in realm names, and it cannot handle lowercase realms in
the [realms] section. After the following patch, it can, and
** Patch added: output of diff -u krb5.aug.old
/usr/share/augeas/lenses/dist/krb5.aug
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+attachment/4065670/+files/krb5.aug.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Public bug reported:
In Trusty, augtool doesn't parse the default /etc/krb5.conf
There are multiple issues. The lens cannot handle some keywords, it cannot
handle heading digits in realm names, and it cannot handle lowercase realms in
the [realms] section. After the following patch, it can, and
Additional information:
The account ADJoiner is an ordinary user in that it has no
servicePrincipalName, whereas hosts do have one. I believe this is a crucial
difference, because I can get a ticket for anything that has a
servicePrincipalName, but not for anything that doesn't.
And indeed,
Public bug reported:
I try to log in using sssd with AD authentication. It fails.
When I remove the first key from the keytab, logging in succeeds.
Restoring the previous keytab brings the failure back.
Hence, I believe the closing of
https://fedorahosted.org/sssd/ticket/1871#comment:2 to be
34 matches
Mail list logo
