Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2004 07:45 PM
тАО07-19-2004 07:45 PM
These scripts worked for years on our old server.
However on our new server logname fails - it comes up with an error - logname: could not get login name. But sometimes if the user logs out and logs back in again, logname works ! Our users also use tsm(if this is the reason?) .
1)Does anyone know the reason for this behaviour.
2)If I substitute logname with a function which returns id -un, would this be a more stable option ?
ANy solution much appreciated as this is quite urgent. Many Thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2004 07:47 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2004 07:55 PM
тАО07-19-2004 07:55 PM
Re: logname
The reason I asked is there is a function already on our server which uses id -un.
Yes Bill- you're right about our server- It is only sort of "new" - only the hardware !!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2004 07:56 PM
тАО07-19-2004 07:56 PM
Re: logname
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2004 08:00 PM
тАО07-19-2004 08:00 PM
Re: logname
Maybe a path definition will be the key, pls assigns the "logname" command with the full path, to determine this use the following command:
#whence logname
If the full path is used into the script files, pls compare it with the "whence" command output, in older systems the path may vary.
Try and tell me something.
Rgds.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2004 08:16 PM
тАО07-19-2004 08:16 PM
Re: logname
Both the systems are using the same path , users have the same path on both systems logname is in /usr/bin/logname. But I am intigued as to why it works sometimes when users log out and log back in ? If it was the path, it should always fail, should it not ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-19-2004 09:36 PM
тАО07-19-2004 09:36 PM
Re: logname
From the getlogin(3C) man page:
---
The getlogin() function retrieves the name of the user currently logged in on a terminal associated with the calling process, as found in /etc/utmp.
At least one of the standard input, standard output, or standard error must be a terminal. For the first of these found that is a terminal, a user must have logged in on that terminal, and that terminal must be the controlling terminal of the session leader process of the calling process's session.
---
So I would assume that *sometimes* the session you are calling logname(1) from is not properly recorded in /etc/utmp. Indeed prgrams that create new sessions like getty(1M), rlogind(1M), telnetd(1M) and ... yes ... also tsm(1) are responsible for recording records to /etc/utmp, using library calls like pututline(3C).
All you can do for 10.20 is "patching, patching and also patching" the above commands/daemons along with libc.
Best regards...
Dietmar.