Bug 258232 - www/chromium not downloading but writing empty images.crdownload files
Summary: www/chromium not downloading but writing empty images.crdownload files
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-chromium (Nobody)
URL: https://www.freshports.org/www/chromium/
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2021-09-02 19:43 UTC by Michael
Modified: 2023-10-10 22:11 UTC (History)
6 users (show)

See Also:
grahamperrin: maintainer-feedback? (chromium)


Attachments
chrome download internals (109.24 KB, image/jpeg)
2021-09-02 21:01 UTC, Michael
no flags Details
on the same page chrome://about you find downloads (57.50 KB, image/png)
2021-09-02 21:05 UTC, Michael
no flags Details
chromium stderr log (3.06 KB, text/plain)
2021-09-16 09:56 UTC, Marko Cupać
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael 2021-09-02 19:43:57 UTC
the problem happens on facebook to astrometry.net, it is not a single site problem, happens with and without ipfw firewall enabled, also the same file can be downloaded with Firefox or Falcon on the same machine

there is no further error somewhere, just the missed download and the crdownload file

the problem started with the last or before last upgrade, now I am with 92.0.4515.159 (Official Build) (64-bit), KDE Neon Plasma 5.22 and FreeBSD amd64 13

the only not so common thing is that I use mobile network bridged on my cellphone (usb tethering) which is working fine 

would be great if somebody could look at this
thanks
Comment 1 Michael 2021-09-02 19:45:39 UTC
this "on facebook to astrometry.net"  should be "FROM facebook to astronomy.net"
Comment 2 Michael 2021-09-02 21:01:58 UTC
Created attachment 227626 [details]
chrome download internals

when you open chrome://about you find download internals where you can past download uris and analise the thing, may be I understand it wrong but they mark it as success but below the content file is not appearing
Comment 3 Michael 2021-09-02 21:05:43 UTC
Created attachment 227627 [details]
on the same page chrome://about you find downloads

this I thing are the partial downloads you made so far and the funny is, after some time (no rule) may be 5 may 30 minutos you click on repeat and the fiel is coming in ... this is not happening when you use the same try again tip on the partial download file or resume on the chromium tab
Comment 4 Marko Cupać 2021-09-03 09:29:57 UTC
(In reply to Michael from comment #3)

This happens to me as well, chromium: 92.0.4515.159 on 13.0-RELEASE-p4 amd64, on multiple websites, including ones on local LAN (namely phpmyadmin export database).
Comment 5 Michael 2021-09-03 11:47:28 UTC
that's good, I always think it's only me :) 
the chromium upgrade from this morning (...159_1) doesn't changed a thing, same problem
Comment 6 Michael 2021-09-03 16:32:45 UTC
hope it helps. same linux version works fine helps nothing, but what I mentioned before about the "downloads" link on the "chrome://about" page the RESUME link works after closing the browser, launch Chromium again, since the downloads are not anymore on the status bar, they still appear in Chrome://about Downloads, then clicking the Resume link and it works, the download completes ...
Comment 7 Michael 2021-09-03 21:18:53 UTC
home-solved :) 

missing /etc/machine-id was the culprit or chromium looking for it in the wrong place, whatever, workaround as follows or linking directly 

cat /var/lib/dbus/machine-id > /etc/machine-id
Comment 8 ice 2021-09-04 08:28:38 UTC
I am hit by a similar issue, but the cause is apparently very different.

91.0.4472.164 was fine, the problems started with 92-something, as far as I remember.

One might call my setup a bit awkward:

/tmp is a separate ZFS dataset, and this is what I have my 'download directory' set to in Chromium
/usr/home is another ZFS dataset which is where the bulk of my home lives
however ~/.local is a symlink to a directory in yet another ZFS data set

This setup stopped working in about Chromium 92.

If I set my 'download directory' to ~/.local/, it starts working again.

It looks like Chromium wants to create a temp file in ~/.local/:

 14121 chrome   NAMI  "/home/ice/.local/share/.org.chromium.Chromium.A1I94j"

and then a bit later

 14121 chrome   NAMI  "/home/ice/.local/share/.org.chromium.Chromium.A1I94j"
 14121 chrome   NAMI  "/tmp/<finalname>.crdownload"
 14121 chrome   CALL  write(0x1d,0x7fffffffcd3f,0x1)
 14121 chrome   RET   rename -1 errno 18 Cross-device link

This made my try pointing Chromium to ~/.local/ as the download directory, and this works (as far as Chromium is now able to produce an actual file).

To be honest this looks a bit odd - if there is a specific directory to download files into, and Chromium is using rename to get to the final file name from the temp file name, why is the temp file being created in a random directory very distinctly not the same as the download directory?

That said, this all may be a red herring - the only thing certain is with this filesystem setup and download dir set to /tmp, Chromium isn't downloading things :)
Comment 9 Michael 2021-09-04 09:26:32 UTC
(In reply to ice from comment #8)
I think that has here nothing to do but with your setup, the download dir for any browser you can set in Browser's settings and why you would have a separated drive or partition for .local
Comment 10 ice 2021-09-04 09:51:38 UTC
(In reply to Michael from comment #9)

Just to ease your concerns: it also doesn't work if the browser download directory is set to /tmp and home and /tmp are on different datasets (and ~/.local is on the same dataset as the rest of home).

I hope having separate filesystems for /tmp and home is OK and that setting the download directory to /tmp is also OK.
Comment 11 Michael 2021-09-04 10:30:13 UTC
(In reply to ice from comment #10)
you might be complicate the simple things, you can but I think there is no nees and no technical necessity to have so much partitions for so little content, any way check your rw rights, you probable have created the resources as root but not using the browser as root, so you probably like to check it
Comment 12 Marko Cupać 2021-09-14 07:44:18 UTC
The problem is not fixed for me.

I temporarily symlinked /var/lib/dbus/machine-id to /etc/machine-id but downloads still fail.

My ~/.local/ is on (home/user) zfs dataset, download dir is (home/user/Downloads) zfs dataset, /tmp is on tmpfs filesystem.

It worked for ages like this, now it doesn't.
Comment 13 Michael 2021-09-15 07:43:53 UTC
(In reply to Marko Cupać from comment #12)

have you looked if there is something in the file?

create the machine-id file first with "dbus-uuid > /var/lib/dbus/" and link it again, you need eventually re-create the file every time after a new kernel install
Comment 14 Marko Cupać 2021-09-15 14:28:29 UTC
(In reply to Michael from comment #13)

Yes, there was string similar to 'ff617793fd231ft1589dd8eb5808beef' (a few characters changed). File was from 2016 (I have been upgrading this machine over the years).

I don't have dbus-uuid on my machine. I have dbus-uuidgen. I re-created with `sudo dbus-uuidgen --ensure`, symlinked to /etc, rebooted, cleared chromium cache but downloads still fail.
Comment 15 Michael 2021-09-15 21:53:47 UTC
(In reply to Marko Cupać from comment #14)

of course it was dbus--uuidgen :) 

let's go over it:

1 dbus-uuidgen > /var/lib/dbus/machine-id
2 ln -s /var/lib/dbus/machine-id /etc/machine-id

you should not use the --ensure switch because it doesn't write a new one what is what should be done

there is no other wodoo like reboot or browser cache involved ok, when it still doesn't work you have some other mix-up in your pc, but probably letting the ensure switch out it will work
Comment 16 Marko Cupać 2021-09-16 09:39:21 UTC
(In reply to Michael from comment #15)

Hi, thanks for trying to help me.

--ensure does not create machine-id if it exists, but I did delete the first one beforehand, so I got new one.

Anyway, deleting it again, recreating new one as you instructed, re-linking to /etc, ensuring they're the same, unfortunately resulted in failed download again.

Terminal output:
me@mybox:~ % sudo rm /etc/machine-id

me@mybox:~ % sudo rm /var/lib/dbus/machine-id

me@mybox:~ % dbus-uuidgen | sudo tee /var/lib/dbus/machine-id
0a3814dfb86501127f1b91d661430cda

me@mybox:~ % cat /var/lib/dbus/machine-id 
0a3814dfb86501127f1b91d661430cda

me@mybox:~ % cat /etc/machine-id 
0a3814dfb86501127f1b91d661430cda

Chrome Downloads:
FreeBSD-13.0-RELEASE-amd64-dvd1.iso Failed - Download error
https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-RELEASE-amd64-dvd1.iso

Chromium is built in my own poudriere, with CUPS disabled, other options are default.

I have temporarily disabled three extensions I use - umatrix, ublock origin and cookie autodelete - no improvement.

Taking into account that everything else works fine on this box, and that also chromium worked fine until recent upgrade, I'd say that mix-up is with chromium itself.
Comment 17 Marko Cupać 2021-09-16 09:56:20 UTC
Created attachment 227933 [details]
chromium stderr log

I started chromium from command line and instructed it to log to stderr with:

chrome --enable-logging=stderr --v=1

Perhaps attached output excerpt will help someone more knowledgeable than me to find something related to the problem.

Those lines seem significant to me:

[10696:111689:0916/114501.056208:VERBOSE1:bus.cc(703)] Requested to remove an unknown filter function: 1 with associated data: 0x819c15c40

[10696:111692:0916/114535.123155:ERROR:component_installer.cc(143)] Move failed.: Socket operation on non-socket (38)
Comment 18 Michael 2021-09-16 10:42:47 UTC
(In reply to Marko Cupać from comment #17)

dear friend, sorry to say it, but when you insist doing things different than I wrote it, then I can't do anything for you and this is also not exactly a chat system, please go to the freebsd irc channel and I'm sure somebody will talk with you 
good luck
Comment 19 Marko Cupać 2021-09-16 10:56:23 UTC
(In reply to Michael from comment #18)

Dear Michael,

I am truly grateful you are trying to help me.

I understand that you solved your problem by regenerating /var/lib/dbus/machine-id and symlinking it to /etc/machine-id, which results in having same content in both of them, and functional chromium downloads for you.

However, if you don't understand that:

# dbus-uuidgen > /var/lib/dbus/machine-id (as root)

and

% dbus-uuidgen | sudo tee -a /var/lib/dbus/machine-id (as standard user with appropriate sudo privileges)

... result in same thing, which is creating /var/lib/dbus/machine-id file with appropriate content - 32-character random alphanumeric string with lowercase letters, I sincerely doubt that you can help me with my issue.

I am glad your chromium downloads work. Sorry for spamming your bug report. I guess I will need to open my own.

Have a nice day,
Comment 20 Michael 2021-09-19 12:23:50 UTC
you may be like to check the -a switch to tee and don't use it
Comment 21 mmatalka 2021-11-03 07:52:04 UTC
I'm running into this issue as well and I have regenerated the dbus uuid and symlinked it.  I noticed that did fix some dbus issues I was having, however my downloads still do not work.

Perhaps some useful log message from chrome:

[2814:102554:1103/084906.987564:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2814:102554:1103/084906.987645:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2814:102561:1103/084938.342474:ERROR:cert_verify_proc_builtin.cc(600)] No net_fetcher for performing AIA chasing.
[2814:102548:1103/084938.981120:ERROR:component_installer.cc(143)] Move failed.: Socket operation on non-socket (38)
[2814:102548:1103/084940.854824:ERROR:component_installer.cc(143)] Move failed.: Socket operation on non-socket (38)
Comment 22 mmatalka 2021-11-03 08:08:43 UTC
(In reply to mmatalka from comment #21)

And sometimes Resuming works and sometimes it doesn't.

I'm on:

Chromium 94.0.4606.81
Comment 23 Michael 2021-11-03 11:34:24 UTC
(In reply to mmatalka from comment #22)

I would suggest to change the urgency and that many people are affected since we do not have any other browser in FreeBSD, Firefox has a horrible file dialog box which is certainly unusable as well
Comment 24 gnikl 2021-11-06 15:32:53 UTC
(In reply to ice from comment #8)
> 14121 chrome   RET   rename -1 errno 18 Cross-device link

I second your finding! There is a change in Chromium v92 that causes downloads (this includes installing extensions) to fail (at least on FreeBSD) if the download destination is on a different filesystem than the temporary file location. In my case Chromium creates the temporary file in /tmp (a tmpfs fs) and the download location is $HOME/Downloads. The downloads appears to be successful but the file in $HOME/Downloads is empty. The data is there but only in the temporary dot file in /tmp. Somehow Chromium on FreeBSD thinks that the download destination is on the same fs as the temporary file location. If I choose /tmp as download destination the download works.

I tried to pinpoint the problematic place in the code but with the amount of changed code between Chromium releases I was not successful so far.
Comment 25 Michael 2021-11-06 21:04:18 UTC
not fixed, the error persists
Comment 26 Michael 2021-11-06 21:17:56 UTC
(In reply to gnikl from comment #24)

I think you're times back with 92, we're now at 94.0.4606.81

also I believe the temporary file thing is a wild guess, chrome creates a .crdownload file, by adding this extension to the original filename and renames it when download is complete, there is nothing in /tmp, the download runs in the selected directory 

cheers
Comment 27 gnikl 2021-11-09 16:02:35 UTC
(In reply to Michael from comment #26)
> I think you're times back with 92, we're now at 94.0.4606.81
There is a "+" character missing, it was supposed to read "v92+".

Since the first non-working version is v92, it makes sense to look at that version. Forward porting the solution should be easy. FWIW, v94 still has that bug.

> there is nothing in /tmp
I my case there is a .dot file in the temporary download location (which in my case is /tmp) which has the missing file content. As I wrote if the download target location and the temp file use different filesystems the download fails. If the download target is on the same filesystem as the temp file (for me this is /tmp) then the download is successful.
Comment 29 Graham Perrin freebsd_committer freebsd_triage 2022-11-20 01:02:45 UTC
(In reply to Graham Perrin from comment #28)

That was for Chromium 97.0.4692.99 in February. 

(In reply to Michael from comment #25)

Please, can you (or a maintainer) tell whether this is fixed? 

We're now at 107.0.5304.110.