If I try to run /etc/cron.daily/apt, it just hangs.



This is a fresh 8.04 server install upgraded to 8.10 (I had to do it that way because the 8.10 CDs wouldn't install for some reason!?)



I've googled around and seen this issue listed, but no solution that works for me so far. Anyone have ideas?



root@daevid:/etc/cron.daily# strace ./apt

execve("./apt", ["./apt"], [/* 17 vars */]) = 0

brk(0)********************************* = 0x9dd3000

access("/etc/ld.so.nohwcap", F_OK)***** = -1 ENOENT (No such file or directory)

mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f92000

access("/etc/ld.so.preload", R_OK)***** = -1 ENOENT (No such file or directory)

open("/etc/ld.so.cache", O_RDONLY)***** = 3

fstat64(3, {st_mode=S_IFREG|0644, st_size=66482, ...}) = 0

mmap2(NULL, 66482, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f81000

close(3)******************************* = 0

access("/etc/ld.so.nohwcap", F_OK)***** = -1 ENOENT (No such file or directory)

open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3

read(3, "177ELF111331340g1"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=1425800, ...}) = 0

mmap2(NULL, 1431152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e23000

mmap2(0xb7f7b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x158) = 0xb7f7b000

mmap2(0xb7f7e000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f7e000

close(3)******************************* = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e22000

set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e228c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0

mprotect(0xb7f7b000, 8192, PROT_READ)** = 0

mprotect(0x805d000, 4096, PROT_READ)*** = 0

mprotect(0xb7faf000, 4096, PROT_READ)** = 0

munmap(0xb7f81000, 66482)************** = 0

getpid()******************************* = 16068

rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0

geteuid32()**************************** = 0

brk(0)********************************* = 0x9dd3000

brk(0x9df4000)************************* = 0x9df4000

getppid()****************************** = 16067

stat64("/etc/cron.daily", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

open("./apt", O_RDONLY)**************** = 3

fcntl64(3, F_DUPFD, 10)**************** = 10

close(3)******************************* = 0

fcntl64(10, F_SETFD, FD_CLOEXEC)******* = 0

rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0

rt_sigaction(SIGINT, {0x8056740, ~[RTMIN RT_1], 0}, NULL, 8) = 0

rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0

rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0

rt_sigaction(SIGTERM, NULL, {SIG_DFL}, 8) = 0

rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0

read(10, "#!/bin/sh
#

#FIXME:
#[dv] added"..., 8192) = 7794

open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3

fcntl64(1, F_DUPFD, 10)**************** = 11

close(1)******************************* = 0

fcntl64(11, F_SETFD, FD_CLOEXEC)******* = 0

dup2(3, 1)***************************** = 1

close(3)******************************* = 0

stat64("/usr/local/sbin/which", 0xbfeae4e8) = -1 ENOENT (No such file or directory)

stat64("/usr/local/bin/which", 0xbfeae4e8) = -1 ENOENT (No such file or directory)

stat64("/usr/sbin/which", 0xbfeae4e8)** = -1 ENOENT (No such file or directory)

stat64("/usr/bin/which", {st_mode=S_IFREG|0755, st_size=946, ...}) = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16069

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16069

--- SIGCHLD (Child exited) @ 0 (0) ---

dup2(11, 1)**************************** = 1

close(11)****************************** = 0

pipe([3, 4])*************************** = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16070

close(4)******************************* = 0

read(3, "UpdateInterval='1'
DownloadUpgra"..., 128) = 51

--- SIGCHLD (Child exited) @ 0 (0) ---

read(3, "", 128)*********************** = 0

close(3)******************************* = 0

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16070

pipe([3, 4])*************************** = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16071

close(4)******************************* = 0

read(3, "AutocleanInterval='0'
", 128) = 22

--- SIGCHLD (Child exited) @ 0 (0) ---

read(3, "", 128)*********************** = 0

close(3)******************************* = 0

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16071

pipe([3, 4])*************************** = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16072

close(4)******************************* = 0

read(3, "", 128)*********************** = 0

--- SIGCHLD (Child exited) @ 0 (0) ---

close(3)******************************* = 0

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16072

open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3

fcntl64(1, F_DUPFD, 10)**************** = 11

close(1)******************************* = 0

fcntl64(11, F_SETFD, FD_CLOEXEC)******* = 0

dup2(3, 1)***************************** = 1

close(3)******************************* = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16073

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16073

--- SIGCHLD (Child exited) @ 0 (0) ---

dup2(11, 1)**************************** = 1

close(11)****************************** = 0

stat64("/usr/local/sbin/on_ac_power", 0xbfeae4e8) = -1 ENOENT (No such file or directory)

stat64("/usr/local/bin/on_ac_power", 0xbfeae4e8) = -1 ENOENT (No such file or directory)

stat64("/usr/sbin/on_ac_power", 0xbfeae4e8) = -1 ENOENT (No such file or directory)

stat64("/usr/bin/on_ac_power", {st_mode=S_IFREG|0755, st_size=1697, ...}) = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16074

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], 0, NULL) = 16074

--- SIGCHLD (Child exited) @ 0 (0) ---

open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3

fcntl64(2, F_DUPFD, 10)**************** = 11

close(2)******************************* = 0

fcntl64(11, F_SETFD, FD_CLOEXEC)******* = 0

dup2(3, 2)***************************** = 2

close(3)******************************* = 0

stat64("/usr/local/sbin/apt-get", 0xbfeae4e8) = -1 ENOENT (No such file or directory)

stat64("/usr/local/bin/apt-get", 0xbfeae4e8) = -1 ENOENT (No such file or directory)

stat64("/usr/sbin/apt-get", 0xbfeae4e8) = -1 ENOENT (No such file or directory)

stat64("/usr/bin/apt-get", {st_mode=S_IFREG|0755, st_size=112812, ...}) = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16076

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16076

--- SIGCHLD (Child exited) @ 0 (0) ---

dup2(11, 2)**************************** = 2

close(11)****************************** = 0

pipe([3, 4])*************************** = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16077

close(4)******************************* = 0

read(3, "", 128)*********************** = 0

--- SIGCHLD (Child exited) @ 0 (0) ---

close(3)******************************* = 0

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16077

pipe([3, 4])*************************** = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16078

close(4)******************************* = 0

read(3, "28880
", 128)**************** = 6

read(3, "", 128)*********************** = 0

--- SIGCHLD (Child exited) @ 0 (0) ---

close(3)******************************* = 0

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 16078

stat64("/usr/local/sbin/sleep", 0xbfeae388) = -1 ENOENT (No such file or directory)

stat64("/usr/local/bin/sleep", 0xbfeae388) = -1 ENOENT (No such file or directory)

stat64("/usr/sbin/sleep", 0xbfeae388)** = -1 ENOENT (No such file or directory)

stat64("/usr/bin/sleep", 0xbfeae388)*** = -1 ENOENT (No such file or directory)

stat64("/sbin/sleep", 0xbfeae388)****** = -1 ENOENT (No such file or directory)

stat64("/bin/sleep", {st_mode=S_IFREG|0755, st_size=26060, ...}) = 0

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD, child_tidptr=0xb7e22908) = 16082

wait4(-1,


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Mon, 2009-02-23 at 21:07 +0100, Markus Schönhaber wrote:


Daevid Vincent:

> If I try to run /etc/cron.daily/apt, it just hangs.
[...]
> stat64("/bin/sleep", {st_mode=S_IFREG|0755, st_size=26060, ...}) = 0
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|
> SIGCHLD, child_tidptr=0xb7e22908) = 16082
> wait4(-1,

Looks pretty normal to me. Among the first things the apt script does is to
sleep for a random amount of time.


So when I expect all my cron.daily tasks to be running at a given time in crontab, they're actually all delayed by some random amount. Since it's name is alphabetically earlier than anything else in the directory, this 'apt' holds up all the scripts below as they're not fired off in threads. *sigh*


If you check the process list, you'll probably see that there's a "sleep"
process that was started by the script - something that the above output from
strace also indicates.




I see that code:



# sleep for a random intervall of time (default 30min)

random_sleep()

{

*** RandomSleep=1800

*** eval $(apt-config shell RandomSleep APT::Periodic::RandomSleep)

*** if [ $RandomSleep -eq 0 ]; then

return

*** fi

*** if [ -z "$RANDOM" ] ; then

******* # A fix for shells that do not have this bash feature.

RANDOM=$(dd if=/dev/urandom count=1 2> /dev/null | cksum | cut -c"1-5")

*** fi

*** TIME=$(($RANDOM % $RandomSleep))

*** sleep $TIME

}



I tried this on my home and work machine and can confirm you're correct.



root@daevid:/etc/cron.daily# date;./apt;date

Mon Feb 23 13:07:56 PST 2009

Mon Feb 23 13:16:58 PST 2009



I did some research and found this:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483177



"The random sleep was added to avoid that the big archive servers/mirrors get hammered at exactly the same time when a lot of machines are switched on, e.g. 9:00 in the morning. '



Who "switches on" a Unix box??! They normally are running 24/7 right?



root:~$ cat /etc/crontab

# m h dom mon dow user command

17 * * * * root*** cd / && run-parts --report /etc/cron.hourly

25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )

52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )



Shows that this is run at 06:25am every day. My work box has the same.

Wouldn't it have made more sense to just randomize this upon install?



I'm just going to change mine to be:



10 * * * * root*** cd / && run-parts --report /etc/cron.hourly

30 5 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

30 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )

30 7 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )



and modify the "apt" script to be:* RandomSleep=300







--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Tue, 2009-02-24 at 00:18 +0100, Markus Schönhaber wrote:


Daevid Vincent:

> So when I expect all my cron.daily tasks to be running at a given time
> in crontab, they're actually all delayed by some random amount. Since
> it's name is alphabetically earlier than anything else in the directory,
> this 'apt' holds up all the scripts below as they're not fired off in
> threads. *sigh*

Hm, you're the first one I know of who expects jobs in cron.daily to be run
precisely at a given time.


I wouldn't say "precisely", however I don't expect some random delay which looks like a hung task to muck up things on me.


In my understanding jobs in cron.daily are to be
run once a day - whenever that may be throughout the day. And since those jobs
are executed sequentially, it's pretty obvious that any delay in one job (be
it caused by a sleep like in the apt script, a slow network or something else)
will affect the execution time of all following jobs.



True.



If I want something to be executed precisely at a given time, I create a real
cron job for it.


Again. True.


> "The random sleep was added to avoid that the big archive
> servers/mirrors get hammered at exactly the same time when a lot of
> machines are switched on, e.g. 9:00 in the morning. '
>
> Who "switches on" a Unix box??! They normally are running 24/7 right?

Interesting that you ask this question in an Ubuntu mailing list. Since IMO
Ubuntu's main success is based on the fact that it provides an easy to set up
*desktop* Linux.


I've been using Linux since it was Slackware on an Amiga 3000 and came on 14 floppies.



I've used RedHat, CentOS, Gentoo, and various others as my servers too.



To me, Ubuntu is just a "more supported" and "prettier UI" with less hassle version of Linux. In another few years, a new contender will come along that's even better I'm sure.



RedHat pissed me off with their dependency hell in RPMs years ago. And then the whole split to Fedora was messy at the time.



I switched to Gentoo, but I've grown VERY tired of re-compiling all the time when the H/W server died, I decided it was time to jump ship to Ubuntu Server (with the GUI added later) (ironic that now, my new Ubuntu server is 4 procs and 4GB RAM and could handle it very nicely I suspect).


And my guess would be that many of those desktops might get switched off in the
evening and switched back on in the morning. At least, this doesn't seem too
unrealistic a guess to me.


Switching off/on a desktop is so bad for the hardware. It's better to just leave them on. Especially any Unix flavor -- for exactly the reasons we're discussing here. Crontabs need to be run. Having them all "catchup" later (via anacron) is a kludge.


Moreover I think we can assume that the people operating the archive servers
know when the load is high and whether the load spikes form a pattern.


Fair enough.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Markus Schönhaber wrote:

> Daevid Vincent:
>
> Hm, you're the first one I know of who expects jobs in cron.daily to be
> run precisely at a given time. In my understanding jobs in cron.daily are
> to be run once a day - whenever that may be throughout the day. And since
> those jobs are executed sequentially, it's pretty obvious that any delay
> in one job (be it caused by a sleep like in the apt script, a slow network
> or something else) will affect the execution time of all following jobs.

Hmmm. Not that obvious - I didn't think the cron jobs waited for one
another at all...
>
>> "The random sleep was added to avoid that the big archive
>> servers/mirrors get hammered at exactly the same time when a lot of
>> machines are switched on, e.g. 9:00 in the morning. '
>>
>> Who "switches on" a Unix box??! They normally are running 24/7 right?

Ack! I'm afraid you're mostly right, but what a ridiculous waste of energy.

> Interesting that you ask this question in an Ubuntu mailing list. Since
> IMO Ubuntu's main success is based on the fact that it provides an easy to
> set up *desktop* Linux.
> And my guess would be that many of those desktops might get switched off
> in the evening and switched back on in the morning. At least, this doesn't
> seem too unrealistic a guess to me.

Even knowing mostly geeks - the sort of people who might be expected to run
a machine 24/7, I don't know many people whose _personal_ machines run
full-time.

--
derek


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Derek Broughton wrote:

>
> Hmmm. Not that obvious - I didn't think the cron jobs waited for one
> another at all...

They don't. Cron.daily is, in fact, 1 cron job. (examine /etc/crontab
to see how it's done)


> Even knowing mostly geeks - the sort of people who might be expected to run
> a machine 24/7, I don't know many people whose _personal_ machines run
> full-time.
>


Huh, that's interesting.. I'll admit the that the reasons to keep a
machine running around the clock are mostly bogus, most geeks I know do
so anyhow.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Derek Broughton:
> Markus Schönhaber wrote:

> > Hm, you're the first one I know of who expects jobs in cron.daily to be
> > run precisely at a given time. In my understanding jobs in cron.daily are
> > to be run once a day - whenever that may be throughout the day. And since
> > those jobs are executed sequentially, it's pretty obvious that any delay
> > in one job (be it caused by a sleep like in the apt script, a slow
> > network or something else) will affect the execution time of all
> > following jobs.
>
> Hmmm. Not that obvious - I didn't think the cron jobs waited for one
> another at all...

<nitpick_mode>
Strictly speaking, the cron jobs don't wait for each other, but rather there's
only one cron job involved - the one which starts run-parts. Which, in turn,
runs the scripts in the cron.daily directory, and does so one after the other.
</nitpick_mode>

Regards
mks


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Markus Schönhaber wrote:
>
> <nitpick_mode>
> Strictly speaking, the cron jobs don't wait for each other, but rather there's
> only one cron job involved - the one which starts run-parts. Which, in turn,
> runs the scripts in the cron.daily directory, and does so one after the other.
> </nitpick_mode>
>
> Regards
> mks
>
>

Details aside, I think we can reasonably agree that a random sleep
holding up the daily cron job is not really expected behaviour and this
can be tuned a little somehow,, (ex, put apt in it's own crantab file
instead of using cron.daily)

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Mon, 2009-02-23 at 21:13 -0500, Rashkae wrote:
> Markus Schönhaber wrote:
> >
> > <nitpick_mode>
> > Strictly speaking, the cron jobs don't wait for each other, but rather there's
> > only one cron job involved - the one which starts run-parts. Which, in turn,
> > runs the scripts in the cron.daily directory, and does so one after the other.
> > </nitpick_mode>
> >
> > Regards
> > mks
> >
> >
>
> Details aside, I think we can reasonably agree that a random sleep
> holding up the daily cron job is not really expected behaviour and this
> can be tuned a little somehow,, (ex, put apt in it's own crantab file
> instead of using cron.daily)

You can always add the --new-session parameter and run-parts will then
run each job in a separate process. I'd experiment with this first,
since you could run the load average up pretty quickly for a short
duration. If you have enough memory and processing power, this is
probably pretty harmless.
--
Smoot Carl-Mitchell
Computer Systems and
Network Consultant
smoot@tic.com
+1 480 922 7313
cell: +1 602 421 9005

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Daevid Vincent wrote:
> Switching off/on a desktop is so bad for the hardware. It's better to
> just leave them on.

Can you explain what part of the hardware will be damaged from regular
switching on/off? I'm using computers at home for >20 years and I have
always switched them off when I'm not at home and during the night. I
don't think I had any harware fail within the first 5 years of their
life.

> Especially any Unix flavor -- for exactly the
> reasons we're discussing here. Crontabs need to be run. Having them all
> "catchup" later (via anacron) is a kludge.

IIRC, this desktop machine I am using right now needs about 70W. If I keep
it running over night only for a few cron jobs it would cost me an extra
40 €uro per year. Therefore I prefer the anacron kludge.


Nils

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Rashkae wrote:

> Derek Broughton wrote:
>
>>
>> Hmmm. Not that obvious - I didn't think the cron jobs waited for one
>> another at all...
>
> They don't. Cron.daily is, in fact, 1 cron job. (examine /etc/crontab
> to see how it's done)

Er, actually /etc/crontab runs run-parts - and I didn't think run-parts was
synchronous. Obviously my mistake - but I was just pointing out that it
wasn't entirely obvious even to somebody of my experience :-)

>> Even knowing mostly geeks - the sort of people who might be expected to
>> run a machine 24/7, I don't know many people whose _personal_ machines
>> run full-time.
>
> Huh, that's interesting.. I'll admit the that the reasons to keep a
> machine running around the clock are mostly bogus, most geeks I know do
> so anyhow.

Almost everybody I know these days uses a laptop as a primary system, and
while we never boot them, they aren't on all the time.
--
derek


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users