[Files sharing] Log message: "/appinfo/app.php is deprecated"

[Valdnet]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Steps to reproduce

I keep getting the following message in my logs:

Debug	files_sharing	/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.	
2020-09-25T14:36:30+0200
Debug	files_sharing	/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.	
2020-09-25T14:36:29+0200
Debug	files_sharing	/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.	
2020-09-25T14:36:29+0200
Debug	files_sharing	/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.	
2020-09-25T14:36:29+0200
Debug	files_sharing	/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.	
2020-09-25T14:36:29+0200

Server configuration

Database:
phpMyAdmin

PHP version:
7.3.16

Nextcloud version: (see Nextcloud admin page)
20.0.0 RC2

App:
Files sharing
1.12.0

[kesselb]

Increase the log level to 1 or higher. It's expected for level debug to log deprecated calls.

[Qinxz1414]

I had the same problem.

[ChristophWurst]

Debug message -> expected.

[andreas-p]

Core apps really shouldn't trigger deprecation messages, but get fixed (arguably prior to a release).
Or other way round: if the implementation of files_sharing is considered stable and future proof, NC shouldn't mark it as deprecated.

[ChristophWurst]

@andreas-p could you check if this green button is blocked for you?

/s

[andreas-p]

@ChristophWurst No it's not. If you're suggesting I should create a PR for this (officially closed!) issue: For my debugging purposes, I commented out the deprecation message in lib/private/legacy/OC_App.php. files_sharing/appinfo/app.php looks different from what I'm familiar with, so I refrained from digging there.

[working-name]

As a user my pull request would simply be disabling the message altogether. But that might be useful for developers. Idea is.. if your "expected debug message" takes a dump on the UI which is user-facing then your "feature" is as useful as this guy's facial tattoo:

Maybe another solution would be to keep deprecation messages away from the UI. Or give the user a way to use filters?

Otherwise this is how much fun you can have as a user trying to debug why the email app chokes on ssl connections:
much fun - 37MB gif

[ChristophWurst]

As a user

So as a user you're complaining about a debug log output. Seriously, why do you worry about this so much? You enable debug mode for a few secs to gather some info, then you disable it again.

Now tell me: would you rather have a silent log where we, the maintainers, can't help you solve an issue due to the lack of information?

[working-name]

you're complaining about a debug log output

No, actually I'm not complaining about a debug log output, and I've already conceded that deprecation notices might be useful for developers. What I'm specifically stating is that deprecation notices at a rate of 3/second is a useless thing in the UI.

Now tell me: would you rather have a silent log where we, the maintainers, can't help you solve an issue due to the lack of information?

I thought deprecation notices are more of a reminder to later tackle the phased out code. Am I wrong?

[ChristophWurst]

With the stateless nature of php it's hard to debounce this. Every request will trigger it.

[working-name]

Okay, understood. Thank you.

[strugee]

In particular, if you're using the Logging app with the auto-refresh option checked in the web UI, the requests generated by the auto-refresh itself will trigger this very frequently. I ran into this myself recently and if you turn that off and then tail the actual log file on the command line, you'll see it settles down.

[working-name]

TBH I saw no harm in commenting out that line and that's how I managed to get a usable UI. But it's a good tip, thank you.

[bcutter]

FYI: Updated from NC 19.0.5.2 to 20.0.2.2 and loglevel was set from 1 to 0 in config.php during update. Machine went totally crazy having Nextcloud.log rotated (cut and moved at 100 MB size) automatically few times. I guess update isn´t reliable yet...

[christianlupus]

I do not want to continue this hate-thread but I fear during development for the cookbook app this issue caused a regression as we were not able to test accordingly. Currently, we are recovering but the main issue can be brought down to this issue.
In fact, I was not able to see the live error logs during testing/debugging the app. So I missed the warning of PHP that a certain set of functions/fields are undefined (typos) and other similar effects. The log was just cluttered with these deprecation warnings (which are good in general). But as these are generated on each invocation (also the update of the logs) this ends in an infinite recursion.

For now, I am able to see some useful information by disabling the files_sharing app but this is no permanent solution, especially as we are planning to allow for the sharing of recipes in the app. At most that moment in time, we need to allow the sharing again, which will clutter the logs again.

I tried to create a patch in this PR but I am not able to get things right, I am missing the knowledge of the internal structure of the NC core.

I am asking @ChristophWurst to reconsider closing this issue as I can only second the general statement/issue here: A component uses a deprecated method and that should be replaced by a newer structure. The fact that it is a core component just makes it hard for other contributors to contribute a "quick fix".

If this is on the agenda for a near-future update, perfect, just give a short statement and I am going to keep waiting.

[Valdnet]

@ChristophWurst I am opening an issue to discuss the problem again.

[dartcafe]

It would be nice to get a solution here fast. I just wanted to track some debug messages while continuing development and this situation still exist.

The problem is not, that a lot of debugging messages are generated because of this deprecation message, the problem is that debugging is impossible ATM. There are something about 45 deprecations messages per second. See the log file snippet in #23351.

[ChristophWurst]

So what would you suggest as a solution?

[dartcafe]

It seems, that the logger itself is responisble for the endless production of deprication warnings in the logfile. If this could be avoided the problem would be smaller and acceptable.

As I am not familiar with the core development, I have no real proposal for a solution.

[dartcafe]

Correction: seems that the files_sharing and contacts are my problem here.

[strugee]

@dartcafe I mentioned this up-thread; see #23046 (comment). You can get a vaguely reasonable log output with tail -f data/nextcloud.log | jq '.time + " " + .reqId + " " + if (.message | type) == "object" then .message.Exception else .message end' (though you will of course need to install jq on your system first). Then the Logging app won't create all the deprecation spam.

[bjo81]

We have loglevel 1 and the log is spammed with deprecation warnings, 25GB log in the last days.

[geep33]

Wth are you talking about

…

On Fri, Jan 22, 2021, 1:36 AM Bjoern Franke ***@***.***> wrote: We have loglevel 1 and the log is spammed with deprecation warnings, 25GB log in the last days. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23046 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARULPN57G2EOV52LAFLOQFDS3E2HVANCNFSM4RZQC2IQ> .

[bjo81]

Wth are you talking about

Some entries above @ChristophWurst says users should not complain about debug output when setting loglevel to debug. I changed loglevel 0 to 1 expecting info messages, but no deprecation warnings. And the logfile grew from 2GB to 25 GB in 4 days, full of deprecation warnings.

[ChristophWurst]

Great now that we have all people combined that complained about the problem, here's the PR that fixes it: #25267

you're welcome

[ChristophWurst]

One step closer to a more reasonable debug log: #25497 ✌️

[Valdnet]

@ChristophWurst Cool 👍. I hope it will be much clearer now and will not take up as much space.

[dartcafe]

The logfile flooding still exists in NC22.

Wouldn't it be a good idea to remove the deprecation at least for the core apps?

I list the following apps in my NC22 installation:

• files_sharing
• contacts
• suspicious_login

[ChristophWurst]

files_sharing

Be my guest and help finish what I was unable to finish #25267 😉

contacts

nextcloud/contacts#1831

suspicious_login

nextcloud/suspicious_login#499

[dartcafe]

files_sharing

Be my guest and help finish what I was unable to finish #25267 😉

I would, if I would have the time and the knowledge. Polls alone takes more time, as I normaly could afford.

[ChristophWurst]

No worries ✌️

We'll have to wait for someone more knowledgeable then because the sharing stuff was also out of my area of expertise and thus got stuck.

[nickvergessen]

File sharing is migrated, so closing this.
Other apps can be added here: #32132