| To: | "'Nathan Scott'" <nathans@xxxxxxxxxx> |
|---|---|
| Subject: | RE: [pcp] pcp updates - pmlc <---> pmlogger access controls |
| From: | "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> |
| Date: | Mon, 5 May 2014 20:11:45 +1000 |
| Cc: | <pcp@xxxxxxxxxxx> |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <1305468312.563111.1399275208034.JavaMail.zimbra@xxxxxxxxxx> |
| References: | <536717E1.7080002@xxxxxxxxxxxxxxxx> <1305468312.563111.1399275208034.JavaMail.zimbra@xxxxxxxxxx> |
| Thread-index: | AQFtEZrjKNcBqX3L28qiyfYnzVF5QADNQE96m/AEB0A= |
> -----Original Message----- > From: Nathan Scott [mailto:nathans@xxxxxxxxxx] > Sent: Monday, 5 May 2014 5:33 PM > ... > I'm seeing a QA failure on 381 - looks like the pmlc flush command is able to > get EPERM under some conditions. Could be a primary logger using the (pre- > existing) system logger config with a new pmlc? > > Since flush is now a no-op, should this just always succeed perhaps, > independent of any permission settings? .bad file attached - everything else > is passing for me here. Thank for this. And I agree. With the next round of changes, pmlc sync/flush is a no-op at the new pmlogger and always returns success. So this means ... old pmlc <--> new pmlogger; does not show a regression new pmlc <--> old pmlogger; historical behaviour preserved new pmlc <--> new pmlogger; flush/sync is a no-op independent of access controls |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [pcp] sosreport and pcp, Ken McDonell |
|---|---|
| Next by Date: | Re: [pcp] sosreport and pcp, Michele Baldessari |
| Previous by Thread: | Re: [pcp] pcp updates - pmlc <---> pmlogger access controls, Nathan Scott |
| Next by Thread: | pcp updates: pmgetopt, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |